Transfer-Encoding support in Squid 2.6

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Transfer-Encoding support in Squid 2.6

Ben Drees
Hi,

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?

Thanks,
Ben
Reply | Threaded
Open this post in threaded view
|

Re: Transfer-Encoding support in Squid 2.6

Ben Drees
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?
Reply | Threaded
Open this post in threaded view
|

Re: Transfer-Encoding support in Squid 2.6

Henrik Nordström
In reply to this post by Ben Drees
fre 2007-06-08 klockan 11:05 -0700 skrev Ben Drees:

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

There is an experimental patch to add partial HTTP/1.1 support to
Squid-2 at http://devel.squid-cache.org/. This might work for you unless
your site is accepting POST/PUT requests.. (100-Continue is not yet
supported).

Regards
Henrik

signature.asc (316 bytes) Download Attachment