[PATCH] Re: proxy_cache handles "304 Not Modified" incorrectly
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:[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, 26 Iyyar 5762, 7 May 2002, 7:06PM
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:[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, 26 Iyyar 5762, 7 May 2002, 6:37PM
[PATCH] Fix for SSLMutex option settings not being honoured
Hi! [Sorry if this is posted twice, but I'm not sure if my first mail got through] With the SSLMutex option the user could (in 1.3.x) ask for file based or semaphore based locking. Now mod_ssl asks APR for the default mechanism completely ignoring the option values. The patch fixes this and changes the SSLMutex command offering these options: default | yes none | no fcntl flock sysvsem posixsem pthread sem = sysvsem | posixsem file: = fcntl | flock The meaning of "yes" changes to "default", "sem" will use either Sys V or Posix semaphores (the former are preferred) and file will use either Fcntl or Flock (preferring Fcntl). The command remains (reasonably) backward compatible and is now in sync with the AcceptMutex command. I deem more than 200 lines too long for listing it here. The patch can be found as an attachment to the accompanying bugzilla bug 8122: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8122 http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=1801 The path adds some diagnostic output in the case of an error and corrects the command description string as well. Masi
Re: proxy_cache handles "304 Not Modified" incorrectly
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 > > >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. > Let me start by saying that RFC 2068 is *obsolete*. The reigning RFC is now 2616. Here are two quotes: 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. 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. 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
Re: [PATCH] Re: Apache.dsw Lost mod_deflate (and makefile.win)
On Tue, 7 May 2002, Jerry Baker wrote: > The following appears to work fine here. Looks okay to my untrained eye. Committed. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
RE: Oversight in tarball scripts?
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]] > Sent: 07 May 2002 09:46 > Seems httpd-2.0.36/test/* is present in the distribution tarballs. > Is this an oversight in the roll-release scripts, or did our good RM > roll the tarball by hand? Your RM used the roll-release script... > I wouldn't pull the tarball over this, it's > simply something worth checking out before .37. Agreed. > -win32 source and binary packages are up and online. Thanks! Sander
Oversight in tarball scripts?
Seems httpd-2.0.36/test/* is present in the distribution tarballs. Is this an oversight in the roll-release scripts, or did our good RM roll the tarball by hand? I wouldn't pull the tarball over this, it's simply something worth checking out before .37. -win32 source and binary packages are up and online.
[PATCH] Re: Apache.dsw Lost mod_deflate (and makefile.win)
The following appears to work fine here.
Index: Apache.dsw
===
RCS file: /home/cvspublic/httpd-2.0/Apache.dsw,v
retrieving revision 1.79
diff -u -r1.79 Apache.dsw
--- Apache.dsw 1 May 2002 15:23:13 - 1.79
+++ Apache.dsw 7 May 2002 07:35:14 -
@@ -750,7 +750,7 @@
###
-Project: "mod_deflate"=".\modules\experimental\mod_deflate.dsp" - Package Owner=<4>
+Project: "mod_deflate"=".\modules\filters\mod_deflate.dsp" - Package Owner=<4>
Package=<5>
{{{
Index: Makefile.win
===
RCS file: /home/cvspublic/httpd-2.0/Makefile.win,v
retrieving revision 1.98
diff -u -r1.98 Makefile.win
--- Makefile.win29 Apr 2002 19:53:55 - 1.98
+++ Makefile.win7 May 2002 07:40:11 -
@@ -81,8 +81,8 @@
!IF EXIST("srclib\zlib")
_tryzlib:
-!IF EXIST("modules\experimental\mod_deflate.mak")
- cd modules\experimental
+!IF EXIST("modules\filters\mod_deflate.mak")
+ cd modules\filters
$(MAKE) $(MAKEOPT) -f mod_deflate.mak CFG="mod_deflate - Win32 $(LONG)"
RECURSE=0 .\$(LONG)\mod_deflate.so
cd ..\..
!ELSE
@@ -208,11 +208,11 @@
$(MAKE) $(MAKEOPT) -f mod_mem_cache.mak CFG="mod_mem_cache - Win32 $(LONG)"
RECURSE=0 $(CTARGET)
$(MAKE) $(MAKEOPT) -f mod_disk_cache.mak CFG="mod_disk_cache - Win32
$(LONG)" RECURSE=0 $(CTARGET)
$(MAKE) $(MAKEOPT) -f mod_ext_filter.mak CFG="mod_ext_filter - Win32
$(LONG)" RECURSE=0 $(CTARGET)
+ cd ..\..
+ cd modules\filters
!IF EXIST("srclib\zlib")
$(MAKE) $(MAKEOPT) -f mod_deflate.mak CFG="mod_deflate - Win32 $(LONG)"
RECURSE=0 $(CTARGET)
!ENDIF
- cd ..\..
- cd modules\filters
$(MAKE) $(MAKEOPT) -f mod_include.mak CFG="mod_include - Win32 $(LONG)"
RECURSE=0 $(CTARGET)
cd ..\..
cd modules\generators
@@ -459,7 +459,7 @@
}
}
<<
- copy modules\experimental\$(LONG)\mod_deflate.so "$(INSTDIR)\modules" <.y
+ copy modules\filters\$(LONG)\mod_deflate.so "$(INSTDIR)\modules" <.y
!ENDIF
copy support\$(LONG)\htdbm.exe "$(INSTDIR)\bin" <.y
copy support\$(LONG)\htdigest.exe "$(INSTDIR)\bin" <.y
--
Jerry Baker
Re: proxy_cache handles "304 Not Modified" incorrectly
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 -- - [EMAIL PROTECTED]"There's a moon over Bourbon Street tonight..." smime.p7s Description: S/MIME Cryptographic Signature
Apache.dsw Lost mod_deflate
mod_deflate moved from ../modules/experimental to ../modules/filters. The apache.dsw file still thinks it should be in /experimental. -- Jerry Baker
