You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Zvi Har'El <rl...@math.technion.ac.il> on 2002/05/06 17:58:11 UTC
proxy_cache handles "304 Not Modified" incorrectly
Dear Apache developers,
I have noticed today that when Microsoft-IIS/5.0 sends a "304 Not Modified"
response to IMS GET request, it (incorrectly IMHO) sends with it a
"Content-Length: 0" header. This is (again IMHO) a bug in IIS, but because of
that, IMS GET request with "Pragma: no-cache" headers are not handled
correctly: When the cache revalidation is done, in ap_proxy_cache_update(), the
content length is reset (in line 1481 in apache_1.3.24, line 1508 in the
current snapshot of apache_1.3.25-dev, file proxy_cache.c), before the status
is checked to be HTTP_NOT_MODIFIED (in line 1513 or 1547 resp). This makes the
erroneous Content-Length: 0 header replace the real length in the cache file
headers, and the file is destroyed. Not this doesn't happen without the
"Pragma: no-cache" header. A possible fix would be do ignore the
"Content-Length" in the response in case of "304 Not Modified", but I think
that perhaps no header in such a response should replace the cached headers!
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)
Monday, 25 Iyyar 5762, 6 May 2002, 6:42PM
[PATCH] Re: proxy_cache handles "304 Not Modified" incorrectly
Posted by Zvi Har'El <rl...@math.technion.ac.il>.
Dear Graham,
To make a long discusion short, I hereby insert my 3-liner patch (for
apache_1.3.24) for the problem. You'll be the judge.
--- proxy_cache.c.orig Wed Mar 13 23:05:32 2002
+++ proxy_cache.c Tue May 7 19:04:28 2002
@@ -1477,6 +1477,11 @@
ap_log_error(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, r->server, "Expiry date calculated %ld", (long)expc);
}
+/* Strip Content-Length from 304 reponse, in case buggy IIS-5.0 sends it! */
+ if (r->status == HTTP_NOT_MODIFIED) {
+ ap_table_unset(resp_hdrs, "Content-Length");
+ }
+
/* get the content-length header */
clen = ap_table_get(resp_hdrs, "Content-Length");
if (clen == NULL)
On Tue, 07 May 2002 18:38:49 +0300, Zvi Har'El wrote about "Re: proxy_cache handles "304 Not Modified" incorrectly":
> On Tue, 07 May 2002 09:44:05 +0200, Graham Leggett wrote about "Re: proxy_cache handles "304 Not Modified" incorrectly":
> > How many versions of IIS v5.0 (ie which service packs) are giving this
> > error? If it's fixed in a further service pack, then that should be the
> > encouraged solution.
>
> This is the most recent version of IIS which gives this error. No service pack
> on it.
--
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, 26 Iyyar 5762, 7 May 2002, 7:06PM
Re: proxy_cache handles "304 Not Modified" incorrectly
Posted by Zvi Har'El <rl...@math.technion.ac.il>.
On Tue, 07 May 2002 09:44:05 +0200, Graham Leggett wrote about "Re: proxy_cache handles "304 Not Modified" incorrectly":
> How many versions of IIS v5.0 (ie which service packs) are giving this
> error? If it's fixed in a further service pack, then that should be the
> encouraged solution.
This is the most recent version of IIS which gives this error. No service pack
on it.
--
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, 26 Iyyar 5762, 7 May 2002, 6:37PM
Re: proxy_cache handles "304 Not Modified" incorrectly
Posted by Graham Leggett <mi...@sharp.fm>.
Joshua Slive wrote:
> > I have noticed today that when Microsoft-IIS/5.0 sends a "304 Not Modified"
> > response to IMS GET request, it (incorrectly IMHO) sends with it a
> > "Content-Length: 0" header.
>
> See:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7847
> At most, we could do a browsermatch env-variable for this, but we
> can't just ignore the header.
How many versions of IIS v5.0 (ie which service packs) are giving this
error? If it's fixed in a further service pack, then that should be the
encouraged solution.
We shouldn't break our code to fix theirs if we can possibly avoid it.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: proxy_cache handles "304 Not Modified" incorrectly
Posted by Zvi Har'El <rl...@math.technion.ac.il>.
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
Re: proxy_cache handles "304 Not Modified" incorrectly
Posted by Joshua Slive <jo...@slive.ca>.
On Mon, 6 May 2002, Cliff Woolley wrote:
> On Mon, 6 May 2002, Joshua Slive wrote:
>
> > See:
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7847
> > At most, we could do a browsermatch env-variable for this, but we
> > can't just ignore the header.
>
> I don't see why not. The RFC says it's invalid IIRC, so why can't we
> just ignore it? "Be lenient in what you accept."
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>
So one possibility would be to simply invalidate the cache and make an
unconditional request. This would, of course, kill performance.
Joshua.
Re: proxy_cache handles "304 Not Modified" incorrectly
Posted by Cliff Woolley <jw...@virginia.edu>.
On Mon, 6 May 2002, Joshua Slive wrote:
> See:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7847
> At most, we could do a browsermatch env-variable for this, but we
> can't just ignore the header.
I don't see why not. The RFC says it's invalid IIRC, so why can't we
just ignore it? "Be lenient in what you accept."
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: proxy_cache handles "304 Not Modified" incorrectly
Posted by Joshua Slive <jo...@slive.ca>.
On Mon, 6 May 2002, Zvi Har'El wrote:
>
> I have noticed today that when Microsoft-IIS/5.0 sends a "304 Not Modified"
> response to IMS GET request, it (incorrectly IMHO) sends with it a
> "Content-Length: 0" header.
See:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7847
At most, we could do a browsermatch env-variable for this, but we
can't just ignore the header.
Joshua.