3 ms·

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 T

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?

CJefferson 14y ago
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.
- firebird84 14y ago
  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.
- 0x0 14y ago
  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.
  - jgrahamc 14y ago
    Correct. Since each connection in my proposal starts with a non-pipelined request the HTTP version number of the response could be examined.
santaragolabs 14y ago
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-range-latest.html#rfc.section.4 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.
- jgrahamc 14y ago
  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.
  - santaragolabs 14y ago
    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.
    - jerf 14y ago

CJefferson 14y ago

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.

firebird84 14y ago
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.
0x0 14y ago
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.
- jgrahamc 14y ago
  Correct. Since each connection in my proposal starts with a non-pipelined request the HTTP version number of the response could be examined.

santaragolabs 14y ago

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-range-latest.html#rfc.section.4 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.

jgrahamc 14y ago
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.
- santaragolabs 14y ago
  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.
  - jerf 14y ago