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/10 11:46:52 UTC
Cached response: 304 send as 200
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
Re: Cached response: 304 send as 200
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 11, 2002 at 06:29:09PM +0200, Roy T. Fielding wrote:
> On Wednesday, September 11, 2002, at 06:04 PM, Graham Leggett wrote:
> > Kris Verbeeck wrote:
> >>>> The response:
> >>>>
> >>>> HTTP/1.0 200
> >>>> Date: Tue, 10 Sep 2002 09:45:39 GMT
> >>>> Server: web server
> >>>> Connection: close
> >>>> etag: "b9829-2269-3cd12aa1"
> >>>
> >>> Another bug - why is an HTTP/1.1 response prefixed with "HTTP/1.0"...?
> >> Nope, there is a force-response-1.0 in httpd.conf for this request. So
> >> normal behaviour.
> >
> > Both Etag and Connection: close are HTTP/1.1 headers, simply changing the
> > version string on a forced-response-1.0 is wrong as I understand it.
> >
> > Can someone clarify what should happen in this case?
>
> No, they are HTTP/1.x headers (there is no such thing as a 1.1 header,
> only features that cannot be sent in response to a 1.0 request).
> Both connection and etag should be sent regardless of protocol version.
Yup. What if the server sends My-Custom-Header? The client certainly
shouldn't roll over and die. To a 1.0 client, it can simply ignore those
"1.1" headers that it doesn't understand.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Cached response: 304 send as 200
Posted by "Roy T. Fielding" <fi...@apache.org>.
On Wednesday, September 11, 2002, at 06:04 PM, Graham Leggett wrote:
> Kris Verbeeck wrote:
>
>>>> The response:
>>>>
>>>> HTTP/1.0 200
>>>> Date: Tue, 10 Sep 2002 09:45:39 GMT
>>>> Server: web server
>>>> Connection: close
>>>> etag: "b9829-2269-3cd12aa1"
>>>
>>> Another bug - why is an HTTP/1.1 response prefixed with "HTTP/1.0"...?
>> Nope, there is a force-response-1.0 in httpd.conf for this request. So
>> normal behaviour.
>
> Both Etag and Connection: close are HTTP/1.1 headers, simply changing the
> version string on a forced-response-1.0 is wrong as I understand it.
>
> Can someone clarify what should happen in this case?
No, they are HTTP/1.x headers (there is no such thing as a 1.1 header,
only features that cannot be sent in response to a 1.0 request).
Both connection and etag should be sent regardless of protocol version.
....Roy
Re: Cached response: 304 send as 200
Posted by Graham Leggett <mi...@sharp.fm>.
Kris Verbeeck wrote:
>>>The response:
>>>
>>> HTTP/1.0 200
>>> Date: Tue, 10 Sep 2002 09:45:39 GMT
>>> Server: web server
>>> Connection: close
>>> etag: "b9829-2269-3cd12aa1"
>>
>>Another bug - why is an HTTP/1.1 response prefixed with "HTTP/1.0"...?
>
>
> Nope, there is a force-response-1.0 in httpd.conf for this request. So
> normal behaviour.
Both Etag and Connection: close are HTTP/1.1 headers, simply changing
the version string on a forced-response-1.0 is wrong as I understand it.
Can someone clarify what should happen in this case?
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: Cached response: 304 send as 200
Posted by Kris Verbeeck <Kr...@ubizen.com>.
Graham Leggett wrote:
> > The response:
> >
> > HTTP/1.0 200
> > Date: Tue, 10 Sep 2002 09:45:39 GMT
> > Server: web server
> > Connection: close
> > etag: "b9829-2269-3cd12aa1"
>
> Another bug - why is an HTTP/1.1 response prefixed with "HTTP/1.0"...?
Nope, there is a force-response-1.0 in httpd.conf for this request. So
normal behaviour.
--
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: Cached response: 304 send as 200
Posted by Graham Leggett <mi...@sharp.fm>.
Kris Verbeeck wrote:
> The response:
>
> HTTP/1.0 200
> Date: Tue, 10 Sep 2002 09:45:39 GMT
> Server: web server
> Connection: close
> etag: "b9829-2269-3cd12aa1"
Another bug - why is an HTTP/1.1 response prefixed with "HTTP/1.0"...?
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
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);
>
> /*
[PATCH] Re: Cached response: 304 send as 200
Posted by Kris Verbeeck <Kr...@ubizen.com>.
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
Some mod_cache + Reverse proxy problems
Posted by Matthieu Estrade <me...@axiliance.com>.
Hi,
I'am trying to use the cache module with reverse proxy, and i have few
problems.
When i'am using a browser with data in cache, like the file test.gif.
If the picture is in my browser cache before my first try with the
reverse proxy,
mod_cache is unable to cache the data, because on the first connection
on the backend server,
it send a 304 to the reverse proxy, and mod_cache is not accepting to
cache 304.(headers only).
Not really a problem because when i clean the browser cache, it's
working well after.
but is it possible to think sending request to the backend server,
telling it to send a 200 and not a 304.(maybe with force headers).
The second problem is with mod_mem_cache and mod_proxy.
When mem_cache is trying to find the length of the data requested, it's
not working, so length is = -1
And when it do the test with the CacheMaxStreamBuffer, it's always
failed because the length must be upper to 0.
Maybe because the backend server send back a 304 too.
I will try to debug more, because my informations are not very good :)
Best regards,
Estrade Matthieu