<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&#39;t see the benefit of making sure that its the same connection that the page was &quot;generated&quot; from.&nbsp; <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>
&gt; Actually, I&#39;ve already tested this protocol against some typical forward<br>
&gt; proxy setups and it hasn&#39;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>&nbsp;</div><div>&nbsp;If you establish a Connection: Keep-Alive with the proxy server, it will leave the connection open to you, but that doesn&#39;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>&nbsp;</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&#39;t that what cookies are supposed to do?&nbsp; Regardless, it sounds like an application-level concern that should be layered on top of the protocol.<br>&nbsp;<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>
&gt;&gt; I&#39;m thinking here that this proposal is basically rewriting the CGI<br>
&gt;&gt; protocol (web server handing off managed request to custom scripts) with the<br>
&gt;&gt; ONLY difference being the asynchronous nature of the request. Perhaps more<br>
&gt;&gt; consideration might be given to how the CGI/HTTP protocols might be updated<br>
&gt;&gt; to allow async communication.<br>
&gt; Rewriting the HTTP spec is not feasible and I&#39;m not even convinced its a<br>
&gt; good idea. HTTP has always been request/response so it would make a lot more<br>
&gt; sense to simply use a new protocol then confuse millions of<br>
&gt; 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>&nbsp;</div><div>You can&#39;t use HTTP 101 Switching Protocols without a Connection: Upgrade header. I think you&#39;ll note that the proposal that started this thread uses just this combination.<br>
&nbsp;<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>
&gt;&gt; Having said that I still see a very strong use case for low-level<br>
&gt;&gt; client-side TCP and UDP. There are ways to manage the security risks that<br>
&gt;&gt; require further investigation. Even if it must be kept same-domain that is<br>
&gt;&gt; better than creating a new protocol that won&#39;t work with existing services.<br>
&gt;&gt; Even if that sounds like a feature - it isn&#39;t. There are better ways to<br>
&gt;&gt; handle access-control for non-WebConnection devices than sending garbage to<br>
&gt;&gt; the port.<br>
&gt; If we put the access control in anything but the protocol it means that we<br>
&gt; are relying on an external service for security, so it would have to be<br>
&gt; something that is completely locked down. I don&#39;t really see what the<br>
&gt; mechanism would be. Can you propose a method for doing this so as to allow<br>
&gt; 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&nbsp; 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>
&gt;&gt; It&#39;s more harmful because an img tag (to my knowledge) cannot be used to<br>
&gt;&gt; brute-force access, whereas a socket connection could. With the focus on<br>
&gt;&gt; DDOS it is important to remember that these sockets will enable full<br>
&gt;&gt; read/write access to arbitrary services whereas existing methods can only<br>
&gt;&gt; write once per connection and generally not do anything useful with the<br>
&gt;&gt; response.<br>
&gt; What do you mean by brute-force access, and how could the proposed protocol<br>
&gt; 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&#39;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>