While checking the code against HTTPbis Range draft I think we have a possible smuggling avenue being enabled by Squid in the form of the Request-Range header.
What I can see there in Squid is parsing Request-Range into the same memory structures as Range. Each time teh header is encountered erasign prior headers data. Then forwarding the results upstream under the name Range. Only one range header is specified. Multiple is udnefined behaviour. So the following request may be interpreted differently by other participants seeing: GET / HTTP/1.1 Range: bytes=0-1000 Request-Range: bytes=257-1000 * Squid will effectively strip the Range: header and relay the Request-Range value in Range: upstream. * agents closer to the client may be interpreting that as only Range: header plus unknown header. Content-Range on the reply should be sorting out what is actually delivered so no problems are visible. But any protection based on the request could be confused or tricked into not processing the reply if it was only checking based on the RFC standard Range header. This type of crafted request will also have the same behaviour in Squid: GET / HTTP/1.1 Range: bytes=0-1000 Range: bytes=257-1000 The proposal(s): A) treating the Request-Range header as obsolete and erasing it without processing? The only mentions I can find online are CVE-2011-3192 about a Flash+Apache vulnerability meaning the header had to be blocked from sending by Flash and XHR mechanisms plus documentation relating. And that its a legacy header from the days of MSIE 3.0 and Nescape. So it looks like a candidate for dropping some more code. B) treating multiple Range headers as an error and dropping them all. This would result in Request-Range being treasted somewhat like Proxy-Connection has been for some time. Either upgraded when its alone, or dropped if there is a collision. FWIW: the specification says any proxy MAY drop Range at its choice. So we are permitted to erase this traffic brokenness in either of the above ways. Amos