Issac Goldstand wrote:
In any case, if we're proxying for an HTTP/1.0 client using HTTP/1.1
(too tired to check if mod_proxy preserves HTTP version - but will try
to check tomorrow if no one beats me to it), or even serving cached
content to a 1.0 client originally received by a 1.1 request, we'd have
to do all this even now, wouldn't we?
As promised, I looked into this. mod_proxy de-chunks the incoming
response, mod_cache caches it un-chunked, without the content-length or
transport-encoding headers, and the content-length output filter decides
what to do with it. Trailers were a bit tricky since I'm not quite sure
that I rolled them properly, but they were stripped from the response
when apache de-chunked the proxy requests. However, they were also
neither cached nor even forwarded to the client.
While looking into this, I also stumbled across a paper[1] summarizing
some key changes between versions 1.0 and 1.1 of the protocol, which
pointed out some useful specific examples[2] about trailers.
Based on that, it seems to me that the sensible thing to do would be to
update the header file to include trailers after the response is
complete (and send them as-is as trailers to the initial client). If
we're already doing that, then it would probably also make sense to
calculate the entity-length to update the headers afterwards. However,
I'm not even sure as to where such things should be implemented, in
mod_cache, mod_proxy(_http), or http filters, or somewhere else entirely?
[1] http://www8.org/w8-papers/5c-protocols/key/key.html
[2]
http://www8.org/w8-papers/5c-protocols/key/key.html#SECTION00062000000000000000
