You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Kris Verbeeck <Kr...@ubizen.com> on 2002/09/11 16:40:15 UTC
[PATCH] Re: Cached response: 304 send as 200
Hi,
Attached is a patch that will solve the 304 turning into 200 response code
problem. It seems that in mod_disk_cache the status line was also saved
and restored from the cache. On a first request it is saved as "200 OK" or
something to the cache file. On subsequent requests it is restored into
r->status_line.
The problem occurs when afterwards mod_cache decides that the response
should be a "304 not modified". The status line is not reset in this case
and send as a "200 OK" response without a body.
The solution: not restoring the status line from the cache. The http
response header filter will then construct a status line starting from
the status code, which is 304. Problem solved.
Kris Verbeeck wrote:
>
> Hi,
>
> When refreshing a page (with IE) the browser sends a 'If-Modified-Since'
> header in the request. As seen in the debug log below, mod_cache has
> verified that the page has not been modified and wants to return an HTTP
> status 304. Somehow this 304 doesn't get to the browser. Instead of
> sending the 304 response apache sends a 200 response without a body
> (see ethereal output of request and response below). This results in the
> browser displaying an empty (white) page.
>
> If a request is send without the 'If-Modified-Since' header then everything
> works OK, i.e. a 200 response is send with the cached body.
>
> I have already been tracing through httpd with gdb, but found nothing.
> Does anyone have any idea about what is going on with the 304 response?
>
> Setup: apache httpd 2.0.40 (with cache patches from CVS)
>
> The request:
>
> GET /index.html HTTP/1.1
> Accept: */*
> Accept-Language: en-us
> Accept-Encoding: gzip, deflate
> If-Modified-Since: Thu, 02 May 2002 12:01:37 GMT; length=8809
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
> Host: pino.be.ubizen.com
> Connection: Keep-Alive
>
> The response:
>
> HTTP/1.0 200
> Date: Tue, 10 Sep 2002 09:45:39 GMT
> Server: web server
> Connection: close
> etag: "b9829-2269-3cd12aa1"
>
> The debug log:
>
> [date] [debug] mod_cache.c(112): cache: URL /index.html is being handled by disk
> [date] [info] disk_cache: Serving Cached URL /index.html
> [date] [info] disk_cache: Served headers for URL /index.html
> [date] [debug] mod_cache.c(216): cache: fresh cache - returning status 304
>
> --
> ir. Kris Verbeeck
> Development Engineer
>
> Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
> T: +32 16 28 70 64
> F: +32 16 28 70 77
>
> Ubizen - We Secure e-business - www.ubizen.com
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
Re: mod_disk_cache backward compatibility? Re: [PATCH] [UPDATED] Re: Cached response: 304 send as 200
Posted by David Burry <db...@tagnet.org>.
> Folks don't read the docs. We know it, just look at the bugzilla
> database. A magic number is much more appropriate, and will
> make it possible to update or read old formats in the future.
A magic number is a great generic efficient simple way to detect the problem
of "omigod, the format's changed," report it, and possibly blow it away
automatically if that can be done efficiently, but I think it would be bad
to clutter up the code base with a lot of code to read all the old formats.
Dave
RE: mod_disk_cache backward compatibility? Re: [PATCH] [UPDATED]Re: Cached response: 304 send as 200
Posted by Bill Stoddard <bi...@wstoddard.com>.
> For now, I've left the status line in the cache header; the
> reader code just reads that line and ignores it. (Thanks to
> Kris for the patch.)
>
> Is there any reason why the header and the content for a cache
> entry are stored in two separate files?
Not really.
> Concatenating them into
> the same file would allow for faster reads, faster cache updates,
> and fewer inodes per cache entry.
+1
Bill
RE: mod_disk_cache backward compatibility? Re: [PATCH] [UPDATED]
Re: Cached response: 304 send as 200
Posted by Brian Pane <br...@apache.org>.
For now, I've left the status line in the cache header; the
reader code just reads that line and ignores it. (Thanks to
Kris for the patch.)
Is there any reason why the header and the content for a cache
entry are stored in two separate files? Concatenating them into
the same file would allow for faster reads, faster cache updates,
and fewer inodes per cache entry.
Brian
On Fri, 2002-09-13 at 13:22, Bill Stoddard wrote:
>
>
> > -----Original Message-----
> > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> > Sent: Friday, September 13, 2002 3:52 PM
> > To: dev@httpd.apache.org
> > Cc: dev@httpd.apache.org
> > Subject: RE: mod_disk_cache backward compatibility? Re: [PATCH]
> > [UPDATED] Re: Cached response: 304 send as 200
> >
> >
> > At 02:42 PM 9/13/2002, Bill Stoddard wrote:
> > > > Kris Verbeeck wrote:
> > > >
> > > > Thanks! One more issue before I commit this...
> > > > The change will require that users clear their file
> > > > caches. Can any of the mod_cache hackers give me a
> > > > second opinion on this? Since mod_file_cache is still
> > > > in experimental state, it reasonable to just make the
> > > > change and document the need to clear one's file cache
> > > > when installing 2.0.4. Or do we need to provide some
> > > > automated checking for this in mod_disk_cache (like
> > > > adding a magic number and format version number in
> > > > the file header)?
> > >
> > >Document the change and inform folks to clear their file cache.
> >
> > Folks don't read the docs. We know it, just look at the bugzilla
> > database. A magic number is much more appropriate, and will
> > make it possible to update or read old formats in the future.
> >
> > Bill
>
> I am really not keen on crufting up the codebase to support backward
> compatability with a module that was unusable up until 2.0.40 and is
> experimental in 2.0.40.
>
> Bill
RE: mod_disk_cache backward compatibility? Re: [PATCH] [UPDATED] Re: Cached response: 304 send as 200
Posted by Bill Stoddard <bi...@wstoddard.com>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Friday, September 13, 2002 3:52 PM
> To: dev@httpd.apache.org
> Cc: dev@httpd.apache.org
> Subject: RE: mod_disk_cache backward compatibility? Re: [PATCH]
> [UPDATED] Re: Cached response: 304 send as 200
>
>
> At 02:42 PM 9/13/2002, Bill Stoddard wrote:
> > > Kris Verbeeck wrote:
> > >
> > > Thanks! One more issue before I commit this...
> > > The change will require that users clear their file
> > > caches. Can any of the mod_cache hackers give me a
> > > second opinion on this? Since mod_file_cache is still
> > > in experimental state, it reasonable to just make the
> > > change and document the need to clear one's file cache
> > > when installing 2.0.4. Or do we need to provide some
> > > automated checking for this in mod_disk_cache (like
> > > adding a magic number and format version number in
> > > the file header)?
> >
> >Document the change and inform folks to clear their file cache.
>
> Folks don't read the docs. We know it, just look at the bugzilla
> database. A magic number is much more appropriate, and will
> make it possible to update or read old formats in the future.
>
> Bill
I am really not keen on crufting up the codebase to support backward
compatability with a module that was unusable up until 2.0.40 and is
experimental in 2.0.40.
Bill
RE: mod_disk_cache backward compatibility? Re: [PATCH]
[UPDATED] Re: Cached response: 304 send as 200
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 02:42 PM 9/13/2002, Bill Stoddard wrote:
> > Kris Verbeeck wrote:
> >
> > Thanks! One more issue before I commit this...
> > The change will require that users clear their file
> > caches. Can any of the mod_cache hackers give me a
> > second opinion on this? Since mod_file_cache is still
> > in experimental state, it reasonable to just make the
> > change and document the need to clear one's file cache
> > when installing 2.0.4. Or do we need to provide some
> > automated checking for this in mod_disk_cache (like
> > adding a magic number and format version number in
> > the file header)?
>
>Document the change and inform folks to clear their file cache.
Folks don't read the docs. We know it, just look at the bugzilla
database. A magic number is much more appropriate, and will
make it possible to update or read old formats in the future.
Bill
RE: mod_disk_cache backward compatibility? Re: [PATCH] [UPDATED] Re: Cached response: 304 send as 200
Posted by Bill Stoddard <bi...@wstoddard.com>.
> Kris Verbeeck wrote:
>
> >Brian Pane wrote:
> >
> >
> >
> >>If the read of this field is removed, won't we also need to remove
> >>the code that writes it?
> >>
> >>
> >
> >Correct, my mistake... new patch has been attached that also removes
> >the writing of the status line.
> >
>
> Thanks! One more issue before I commit this...
> The change will require that users clear their file
> caches. Can any of the mod_cache hackers give me a
> second opinion on this? Since mod_file_cache is still
> in experimental state, it reasonable to just make the
> change and document the need to clear one's file cache
> when installing 2.0.4. Or do we need to provide some
> automated checking for this in mod_disk_cache (like
> adding a magic number and format version number in
> the file header)?
Document the change and inform folks to clear their file cache.
>
> Brian
Bill
mod_disk_cache backward compatibility? Re: [PATCH] [UPDATED] Re:
Cached response: 304 send as 200
Posted by Brian Pane <br...@apache.org>.
Kris Verbeeck wrote:
>Brian Pane wrote:
>
>
>
>>If the read of this field is removed, won't we also need to remove
>>the code that writes it?
>>
>>
>
>Correct, my mistake... new patch has been attached that also removes
>the writing of the status line.
>
Thanks! One more issue before I commit this...
The change will require that users clear their file
caches. Can any of the mod_cache hackers give me a
second opinion on this? Since mod_file_cache is still
in experimental state, it reasonable to just make the
change and document the need to clear one's file cache
when installing 2.0.4. Or do we need to provide some
automated checking for this in mod_disk_cache (like
adding a magic number and format version number in
the file header)?
Brian
[PATCH] [UPDATED] Re: Cached response: 304 send as 200
Posted by Kris Verbeeck <Kr...@ubizen.com>.
Brian Pane wrote:
> If the read of this field is removed, won't we also need to remove
> the code that writes it?
Correct, my mistake... new patch has been attached that also removes
the writing of the status line.
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
Re: [PATCH] Re: Cached response: 304 send as 200
Posted by Brian Pane <br...@apache.org>.
On Wed, 2002-09-11 at 07:40, Kris Verbeeck wrote:
> Hi,
>
> Attached is a patch that will solve the 304 turning into 200 response code
> problem. It seems that in mod_disk_cache the status line was also saved
> and restored from the cache. On a first request it is saved as "200 OK" or
> something to the cache file. On subsequent requests it is restored into
> r->status_line.
If the read of this field is removed, won't we also need to remove
the code that writes it?
-Brian
> --- mod_disk_cache.c Wed Sep 11 16:33:25 2002
> +++ mod_disk_cache.c-PATCHED Wed Sep 11 16:32:54 2002
> @@ -484,6 +484,17 @@
>
> r->status = atoi(urlbuff); /* Save status line into request rec */
>
> + rv = apr_file_gets(&urlbuff[0], urllen, dobj->hfd); /* Read status line */
> + if (rv != APR_SUCCESS) {
> + /* XXX log message */
> + return rv;
> + }
> +
> + if ((temp = strchr(&urlbuff[0], '\n')) != NULL) /* trim off new line character */
> + *temp = '\0'; /* overlay it with the null terminator */
> +
> + r->status_line = apr_pstrdup(r->pool, urlbuff); /* Save status line into request rec */
> +
> h->req_hdrs = apr_table_make(r->pool, 20);
>
> /*