3 ms·
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 num
by 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 agoTo 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 agoEven 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 agoCorrect. Since each connection in my proposal starts with a non-pipelined request the HTTP version number of the response could be examined.