httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zvi Har'El" ...@math.technion.ac.il>
Subject Re: proxy_cache handles "304 Not Modified" incorrectly
Date Tue, 07 May 2002 13:13:41 GMT
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:rl@math.technion.ac.il     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

Mime
View raw message