Search squid archive

Re: Transfer-Encoding support in Squid 2.6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ben Drees wrote:
I'm running Squid 2.6 STABLE12 as a reverse proxy. The origin servers are Apaches (2.0.58) configured to gzip most responses (which are all dynamic) with mod_deflate. The fact that Squid is an HTTP 1.0 client has the undesirable effect, in this scenario, that every compressed response results in a connection closure. If I use telnet to replay a forwarded request, changing only the "HTTP/1.0" to "HTTP/1.1", the response includes "Transfer-Encoding: chunked" and "Connection: Keep-Alive" rather than "Connection: Close". If only there were some other way to produce this outcome.

It looks like Squid includes some code that supports "Transfer-Encoding: chunked", so my question is: How can Apache (or any other origin server) be coaxed into using "Transfer-Encoding: chunked" in its responses if Squid advertises itself as an HTTP 1,0 client? Is that code in Squid only as a best effort patch to deal with responses inappropriately transfer-encoded by origin servers?

What sorts of things would break if Squid advertised itself as an HTTP 1.1 client?

I see now that Squid 2.6 can read Transfer-Encoded responses, but turns them into HTTP-1.0-style responses to the client, with "Connection: Close" and no Content-Length.

Can Squid 3 do HTTP 1.1?

[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux