Hacker News Reader

Comment by samwillis | Hacker News Reader

I like this, it seems so much more clean than SPDY, HTTP really should stay a text based protocol. My understanding for the design of SPDY was that by forcing TLS it ensured that any proxy server in the middle wouldn't interfere or be "confused" with the connection.

What would an existing proxy server (i.e. doesn't understand HMURR) do with a connection that looked like this?

View on HN

That is I think one of the big problems with this suggestion.

The world is full of proxies and html-consuming tools that do not bother to check the version number, which would get horribly confused by this, and probably mangle the stream.

I was under the impression one of the reasons SPDY is so different is precisely to try to avoid problems with bad proxies. I'm not an expert on this unfortunately, but I'm sure that quite a few bits of the web-proxy standard involved getting around badly behaving proxies, and they had to do a few strange things.

Even if the tool does not check the version number in the request, wouldn't any proxied response contain a HTTP/1.0 or HTTP/1.1 header? In that case, the client will see all but the first request in a connection stands no chance of being fulfilled, and fall back to HTTP/1.1 behaviour (perhaps caching a NO_HTTP_1_2 flag per hostname for a while)

Edit: Or also add an "Upgrade: slices" to the initial request, and if the expected response to the Upgrade: request is missing, continue with HTTP 1.1.

Correct. Since each connection in my proposal starts with a non-pipelined request the HTTP version number of the response could be examined.

To be honest, I wouldn't be surprised. Proxies are precisely one of the reasons the WebSockets protocol has been changed to be such a pain in the ass compared to its original incarnation. I suggest checking out its original proposal and compare it to the draft RFC - it's rather enlightening.

It depends. A SOCKS proxy would continue to work perfectly; no changes needed there. But most production networks use HTTP proxying; assuming that they do not do MITM attacks (sometimes for legitimate inspection/compliance reasons) on the SSL traffic it will mean that HTTPS will continue to work perfectly too since that normally runs over a simple HTTP CONNECT Proxy which functions the same as a SOCKS proxy.

So that leaves the standard HTTP proxying. The HTTP proxy might treat the 2nd to nth request as being the payload of the HTTP request and may insert Content-Length headers. The HTTP proxy might filter out unknown HTTP headers (would be pretty bad; it's like the common example of where strict firewall admins tend to drop all ICMP packets). There will be security issues related to colliding Request-ID's and to the caching of it.

Also I don't see why we would need the Slice-Length. Just re-use the Content-Range header, that's what it's for right? (http://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-r...).

The standard HTTP pipelining is quite old and very well specified but afaik none of the major browsers implement it; I'm not sure why though. Maybe it depends on the lack of server support.

I do not propose to use Content-Range or 206 Partial Content because they already have a defined use. 206 Partial Content is used to response to a request for a specific range.

Okay, guess that makes sense; personally I wouldn't mind having this dual usage but maybe it would make the W3 spec people throw a hissy fit.

Interesting attempt I must say but I think it will be hard to actually get it out there. Too much legacy stuff in the way.

It's a bit like how for a really long time a lot of fancy new VOIP protocols were really hindered by the lack of proper NAT support leading to all these horrible workarounds to do NAT hole punching or more RFC's like STUN and TURN.

"personally I wouldn't mind having this dual usage but maybe it would make the W3 spec people throw a hissy fit."

They would be right to do so. 206 implies that the request is done. It is a very fundamental difference for 206 to stop meaning that. One can not just gloss over the fact that one of the connection may very well have closed the TCP stream. That's not a theoretical objection, that's a very pragmatic one.

Reply on news.ycombinator.com