<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think we should have both a pure TCPSocket, and also a ServerSocket<br>
that keeps the same connection as the original document was downloaded<br>
from. The ServerSocket will make it very easy for web developers to<br>
work with, since the ServerSocket object will be available both from<br>
the server side and the client side while the page is being generated.<br>
I am posting a separate proposal that describes my idea soon.<br>
<div class="Ih2E3d"></div></blockquote><div><br>I don't see the benefit of making sure that its the same connection that the page was "generated" from. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
> Actually, I've already tested this protocol against some typical forward<br>
> proxy setups and it hasn't caused any problems so far.<br>
<br>
</div>Could you test keeping the same connection as the webpage was fetched<br>
from, open? So that when the server script responds with its HTML-code<br>
- the connection is not closed, but used for kept alive for two way<br>
communications?</blockquote><div> </div><div> If you establish a Connection: Keep-Alive with the proxy server, it will leave the connection open to you, but that doesn't mean that it will leave the connection open to the back end server as the Connection header is a single-hop header. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
This gives the following benefits:<br>
<br>
The script on the server decides if the connection should be closed or<br>
kept open. (Protection against DDOS attacks)</blockquote><div> </div><div>With the proposed spec, the server can close the connection at any point. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
This allows implementing server side listening to client side events,<br>
and vice versa. If this works, then the XMLHttpRequest object could be<br>
updated to allow two way communications in exactly the same way.<br>
</blockquote><div><br>The previously proposed protocol already allows the server side listening to client side events, and vice versa. Rather or not to put that in the XMLHttpRequest interface is another issue. I think making XHR bi-directional is a bad idea because its confusing. Better to use a brand new api, like WebSocket.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Also, by adding a SessionID header sent from the client (instead of<br>
storing session ids in cookies), the web server could transparently<br>
rematch any client with its corresponding server side process in case<br>
of disconnect.<br>
<div class="Ih2E3d"></div></blockquote><div><br>Isn't that what cookies are supposed to do? Regardless, it sounds like an application-level concern that should be layered on top of the protocol.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
>> I'm thinking here that this proposal is basically rewriting the CGI<br>
>> protocol (web server handing off managed request to custom scripts) with the<br>
>> ONLY difference being the asynchronous nature of the request. Perhaps more<br>
>> consideration might be given to how the CGI/HTTP protocols might be updated<br>
>> to allow async communication.<br>
> Rewriting the HTTP spec is not feasible and I'm not even convinced its a<br>
> good idea. HTTP has always been request/response so it would make a lot more<br>
> sense to simply use a new protocol then confuse millions of<br>
> developers/administrators who thought they understood HTTP.<br>
<br>
</div>The HTTP spec has these features already:<br>
<br>
1: Header: Connection: Keep-Alive<br>
2: Status: HTTP 101 Switching Protocol<br>
<br>
No need to rewrite the HTTP spec at all probably.</blockquote><div> </div><div>You can't use HTTP 101 Switching Protocols without a Connection: Upgrade header. I think you'll note that the proposal that started this thread uses just this combination.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
>> Having said that I still see a very strong use case for low-level<br>
>> client-side TCP and UDP. There are ways to manage the security risks that<br>
>> require further investigation. Even if it must be kept same-domain that is<br>
>> better than creating a new protocol that won't work with existing services.<br>
>> Even if that sounds like a feature - it isn't. There are better ways to<br>
>> handle access-control for non-WebConnection devices than sending garbage to<br>
>> the port.<br>
> If we put the access control in anything but the protocol it means that we<br>
> are relying on an external service for security, so it would have to be<br>
> something that is completely locked down. I don't really see what the<br>
> mechanism would be. Can you propose a method for doing this so as to allow<br>
> raw tcp connections without security complications?<br>
<br>
</div>TCPConnections are only allowed to the server where the script was<br>
downloaded from (same as Flash and Java applets). A DNS TXT record can<br>
create a white list of servers whose scripts can connect. Also the<br>
TCPConnection possibly should be allowed to connect to local network<br>
resources, after a security warning - but only if the server has a<br>
proper HTTPS certificate.<br>
<div class="Ih2E3d"></div></blockquote><div><br>How would a DNS TXT record solve the problem? I could register <a href="http://evil.com">evil.com</a> and point it at an arbitrary ip address and claim that anyone who wants to can connect.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
>> It's more harmful because an img tag (to my knowledge) cannot be used to<br>
>> brute-force access, whereas a socket connection could. With the focus on<br>
>> DDOS it is important to remember that these sockets will enable full<br>
>> read/write access to arbitrary services whereas existing methods can only<br>
>> write once per connection and generally not do anything useful with the<br>
>> response.<br>
> What do you mean by brute-force access, and how could the proposed protocol<br>
> be used to do it. Can you provide an example?<br>
<br>
</div>With the security measures I suggest above, there is no need for<br>
protection against brute force attacks. Most developers only use one<br>
server per site, and those that have multiple servers will certainly<br>
be able to add a TXT-record to the DNS.<br>
</blockquote></div><br>I don't actually understand which part of the specification you want to change aside from doing the access control in a DNS TXT record instead of the protocol.<br><br>-Michael Carter<br>