[whatwg] Suggestion of an alternative TCPConnection implementation

[Frode Børli]

> I think a major problem with raw TCP connections is that they would be
> the nightmare of every administrator. If web pages could use every
> sort of homebrew protocol on all possible ports, how could you still
> sensibly configure a firewall without the danger of accidentally
> disabling mary sue grandmother's web application?

I dont think so, as long as the web page could only connect to its origin
server. I am certain that this problem was discussed when Java applets
were created also.

Web pages should only be allowed to access other servers when the
script has been digitally signed, and when the user has agreed to
giving the script elevated privileges - or there should be a
certificate on the origin server which is checked against DNS records
for each server that the script attempts to connect to.

> Also keep in mind the issue list Ian brought up in the other mail.
> Things like URI based adressing and virtual hosting would not be
> possible with raw TCP. That would make this feature a lot less useable
> for authors that do not have full access over their server, like in
> shared hosting situations, for example.

Hmm.. There are good arguments both ways. I would like both please :)

So what we want is a http based protocol which allow the client to
continue communicating with the script that handles the initial
request. I believe that a great way to implement this would be to
extend the http protocol (and by using the Connection: Keep-Alive
header).

It should be the script on the server that decides if the connection
is persistent. This will avoid most problems with cross domain
connections, i believe. Lets imagine two php-scripts on a web server:

/index.php (PHP script)
/persistent.pphp (persistent PHP script)

If the user types in the address http://host.com/persistent.pphp -
then this use case is followed:

1. Client sends GET /persistent.pphp and its headers (including domain
name and cookies etc). After all headers are sent, it expects a
standard http compliant response.
2. Server checks the Accept: header for HTML 5 support.
3 (alternative flow): If no support is found in the Accept headers, a
HTTP 406 Not Acceptable header is sent with an error message saying
that a HTML 5 browser is required.
4 (alternative flow). Server checks the (new) SessionID header if it
should reconnect the client to an existing server side instance.
4. Server side script processes the request and may reply with a
complete html page (or with simply a Hello message - it is the server
side script that decides). Server must send Connection: Keep-Alive and
Connection-Type: Persistent headers.
4. The browser renders the response - but a singleton object is
magically available from javascript; document.defaultHTMLSocket. This
object allows the client to continue communicating with the script
that generated the page by sending either serialized data in the same
form as GET/POST data or single text lines.

Other use case: User visits /index.php - which will connect to
/persistent.pphp using javascript.

1. Javascript: mySocket = new HTTPSocket("/persistent.php");
2. Exactly the same use case as the previous is followed, except that
the HTTPSocket-object is returned. The initial data sent by the server
must be read using the read() method of the HTTPSocket object.


Of course, I have not had time to validate that everything I have
suggested can be used and I would like more people to review this
suggestion - but I think it looks very viable at first glance.


I see one problem, and that is if the connection is lost (for example
because of a proxy server):

This could be fixed creating a new header ment for storing a client
session id. If we standardize on that, the web server could
automatically map the client back to the correct instance of the
server application and neither the client, nor the server application
need to know that the connection was lost.


Any feedback will be appreciated.

> Couldn't this already be done today, though? You can already today
> connect to an arbitrary server on an arbitrary port using forms,
> <img>, <script src=""> and all other references that cannot be
> cross-domain protected for backwards compatibillity reasons. The whole
> hotlinking issue is basically the result of that.
> How would WebSocket connections be more harmful than something like
>
> setInterval(function(){
>   var img = new Image();
>   img.src = "http://victim.example.com/" + generateLongRandomString();
> }, 1000);
>
> for example would?
>

Yes, that could be done - but I think that it would be a lot more
painful for the server if the connection was made to some port, and
kept open. Handling a request for a non-existing url can be finished
in microseconds, but if the client just opens a port without being
disconnected, then the server will quickly be overloaded overloaded by
too many incoming connections.
--
Best regards / Med vennlig hilsen
Frode Børli
Seria.no

Mobile:
+47 406 16 637
Company:
+47 216 90 000
Fax:
+47 216 91 000


Think about the environment. Do not print this e-mail unless you really need to.