- From: Frode Børli <frode@seria.no>
- Date: Thu, 19 Jun 2008 00:53:04 +0200
> 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.
Received on Wednesday, 18 June 2008 15:53:04 UTC