httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Nordstrom <...@squid-cache.org>
Subject Re: mod_cache responsibilities vs mod_xxx_cache provider responsibilities
Date Wed, 20 Sep 2006 21:40:51 GMT
tor 2006-09-21 klockan 00:19 +0300 skrev Issac Goldstand:

> The only really relevant line I saw (in a quick 15 minute review) is RFC
> 2616-3.6 (regarding transfer-encodings):
>    "Transfer-coding values are used to indicate an encoding
>    transformation that has been, can be, or may need to be applied to an
>    entity-body in order to ensure "safe transport" through the network.
>    This differs from a content coding in that the transfer-coding is a
>    property of the message, not of the original entity."
> 
> Based on that, it seems to be ok.  However, we'd have to remove strong
> ETags as a side-effect if it was done (since strong ETags change when
> entity headers change).

Hmm... transfer-encoding is a function of the transport alone, not the
entity. Don't mix these up. The entity is unaltered by
transfer-encoding, it's only how it's transferred over the transport
(i.e. TCP) which is altered. This also means that transfer-encoding is
hop-by-hop. In applications layered along the intentions of the RFC then
a cache (any level, browser or proxy) would never see any transfer
encoding as this should have been decoded by the receiving protocol
handler, only identity encoding should be seen.

This is different from Content-Encoding which does alter the entity as
such. Modifications of the Content-Encoding must also account for ETag:s
as no two entity variants of the same URL may carry the same strong
ETag.

> And move trailers into headers (another reason
> to rewrite the headers file at the end).  And probably other things
> which I'm not think of...

Thats always ok. the division of main and trailer headers is also mainly
a transport thing. Only available with chunked encoding btw as it's the
only transfer mechanism which allows for a tralier. The specs allows you
to drop any trailer headers if hard to deal with or to merge them with
the main header if you can.

In direct chunked->chunked proxy transfer you should proxy the trailer
as well. In chunked->identiy transfer (i.e. HTTP/1.1 response ->
HTTP/1.0 client) the tralier is silently dropped as there is no means to
transfer the trailer in HTTP/1.0, and you can't rewind a TCP stream to
add data earlier...

Regards
Henrik

Mime
View raw message