[whatwg] General TCP connections API?

[Charles Iliya Krempeaux]

Hello,

On 5/26/05, Kornel Lesinski <kornel at ldreams.net> wrote:
> 
> > The client is polling the server.  And often a new TCP
> > connection is created (and later tore down) each time the server is
> > polled.  (Which, IMO, is bad.)
> 
> HTTP/1.1 uses persistent connections by default. If you set long keepalive
> time on your webserver, chances are that all requests are going to be done
> over same TCP/IP connection.

Setting HTTP/1.1 persistent connection to a "long time" and the
"iframe" technique (that you described below) both seem like hacks. 
I.e., we're using these things in ways that they were not suppose to
be used.

It was my understanding that one of the purposes of the WHATWG is to
do these things we want to do (with web applications) in an easy way.

For example, we can create "menus" with existing technologies --
DHTML.  But the code is very ugly and complex.  (DHTML has poor
"developer usability".)  It would be better if, for example, if HTML
provided tags for this.  (Like the way XUL does.)


> To have your own connections you'd have to use other port than 80 and that
> may be disallowed on many restricted systems.

Could you please elaborate on this.  (Who's doing the restriction? 
The server or the client?)


> If user navigates to the next page, browser will destroy your JS objects
> and close their connections. That may result in worse performance than
> with HTTP connection that is kept alive between pages.

I don't really see this as a problem.  A web application would be "one
page" (with possibly other pages embedded in it).  In practice, I
don't think you will have to worry about this.  (But if you disagree,
please explain.)

> Even if connections are limited to the same host, you couldn't safely
> serve anything else on it. Spammers might use numerous HTML-injection
> techniques to send spam using other people's computers, and this may get
> much worse if host restriction fails. From past experience of hundreds of
> cross-site scripting vulnerabilities, you can be sure that this will
> happen sooner or later.

Could you please elaborate on this.

I'm guess what you are saying is that a "host" could potentially have
multiple "web sites" on it using "named virtual hosts".  And although
you can separate out multiple sites with HTTP (using "named virtual
hosts"), it is not always possible with other protocols.  Also, if you
can create TCP connections to the same "host" then you could fake the
HTTP "Host" field, and access another site.  Is this what you are
saying?  (Is there anything else?)

If this is the case, then perhaps there needs to be another protocol
created that provides something like TCP connections but is "host"
aware (just like HTTP).  This would be analogous to UDP packets and IP
packets.  (UDP packets are alot like IP packets, from the developers
point of view.)

Is something like this out of the scope of the WHATWG?

If it is "out of scope" then perhaps we could just allow TCP
connections to the same host, but only to a predefined port range
(that common systems, like SMTP don't use.)  And then web application
developers could create the "custom protocols" to use one of those
ports.


> BTW: There's a hack that lets you get data from server without polling -
> use iframe, start sending its contents and don't close connection - keep
> sending <script> elements one by one.

Please refer to my top comment.


See ya

-- 
     Charles Iliya Krempeaux, B.Sc.

     charles @ reptile.ca
     supercanadian @ gmail.com
___________________________________________________________________________
  Wikibooks, Free Open-Content Books                  http://wikibooks.org/