On Mon, 06 May 2002 10:09:02 -0700, Joshua Slive wrote about "Re: proxy_cache handles
"304 Not Modified" incorrectly":
> On Mon, 6 May 2002, Cliff Woolley wrote:
>
> Hmmm.... One quote is
>
> <rfc2068>
> If a cache uses a received 304 response to update a cache entry, the
> cache MUST update the entry to reflect any new field values given in
> the response.
> </rfc2068>
Let me start by saying that RFC 2068 is *obsolete*. The reigning RFC is now
2616. Here are two quotes:
<rfc2616>
10.3.5 304 Not Modified
If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD
respond with this status code. The 304 response MUST NOT contain a
message-body, and thus is always terminated by the first empty line
after the header fields.
The response MUST include the following header fields:
- Date, unless its omission is required by section 14.18.1
If a clockless origin server obeys these rules, and proxies and
clients add their own Date to any response received without one (as
already specified by [RFC 2068], section 14.19), caches will operate
correctly.
- ETag and/or Content-Location, if the header would have been sent
in a 200 response to the same request
- Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same
variant
If the conditional GET used a strong cache validator (see section
13.3.3), the response SHOULD NOT include other entity-headers.
Otherwise (i.e., the conditional GET used a weak validator), the
response MUST NOT include other entity-headers; this prevents
inconsistencies between cached entity-bodies and updated headers.
</rfc2616>
<rfc2166>
7.1 Entity Header Fields
Entity-header fields define metainformation about the entity-body or,
if no body is present, about the resource identified by the request.
Some of this metainformation is OPTIONAL; some might be REQUIRED by
portions of this specification.
entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.11
| Content-Language ; Section 14.12
| Content-Length ; Section 14.13
| Content-Location ; Section 14.14
| Content-MD5 ; Section 14.15
| Content-Range ; Section 14.16
| Content-Type ; Section 14.17
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
extension-header = message-header
The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and MUST be forwarded by
transparent proxies.
</rfc2616>
The RFC tells you exactly which headers may be sent with a 304 Not modified
reply, and which are not. Logically, if an object is not modified, none of its
intrinsic properties, like length, last modified type, content type, etc.
cannot be changed. On the other hand, it is possible that the expiration of an
object may be extended without changing it. I think that the IIS bug is a
result of a code which sends explanatory HTML text with error replies, which in
this case shouldn't be send. The "Content-Length" they specify is the length of
the empty body, not the length of the entity!!!. Of course, we don't need to
fix all IIS bugs, but we should behave reasonably: Whatever garbage headers the
server sends, we should only use the valid ones, and ignore the others, if we
can. The fix is not hard, and it will just improve the apache's proxy quality,
rather then just blame the bad guy.
Best,
Zvi.
--
Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics
tel:+972-54-227607 Technion - Israel Institute of Technology
fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL
"If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
Tuesday, 25 Iyyar 5762, 7 May 2002, 3:41PM
