[whatwg] TCPConnection feedback
ian at hixie.ch
Tue Jun 17 21:35:32 PDT 2008
On Wed, 18 Jun 2008, Shannon wrote:
> > ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
> I understand the reasoning but I do not believe this should be limited
> to ports 80 and 443.
You misunderstand; it's not the ports that are limited, it's just that the
traffic can now pass for HTTP. This would all still work over any
> > HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is
> > going to send back the appropriate handshake response.
> It is always possible that non-http services are running on port 80. One
> logical reason would be as a workaround for strict firewalls. So the main
> defense against abuse is not the port number but the handshake.
Indeed, we would need to very carefully define exactly what the server
must send back, much like in the original protocol -- it would just look a
lot more like HTTP. This would include at least one custom header or value
that you wouldn't see elsewhere (e.g. the Upgrade: header with the magic
> Since the script author can also inject URIs into the handshake this
> becomes a potential flaw.
Indeed, we'd have to throw if the URI wasn't a valid URI (e.g. if it
> One last thing. Does anybody know how async communication would affect
> common proxies (forward and reverse)? I imagine they can handle large
> amounts of POST data but how do they feel about a forcibly held-open
> by-directional communication that never calls POST or GET?
That's basically what TLS is, right? The simple solution would be to just
tunnel everything through TLS when you hit an uncooperative proxy.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg