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.
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.
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.