You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Graham Leggett <mi...@sharp.fm> on 2001/05/22 01:08:54 UTC
mod_headers and 304 Not Modified
(I'm reposting this, I think it fell through the cracks)
rbb@covalent.net wrote:
> > How about a new hook for adding AP_FTYPE_HTTP_HEADER filters?
>
> IMO, this should be fixed by adding the three filters above in a
> core_insert_filter phase. Then, mod_headers can easily be run before the
> core's insert_fitler phase. Problem solved.
Trouble is - there is one last problem. mod_headers works great, but not
on 304 Not Modified responses.
The reason why is this bit of code in ap_http_header_filter():
if (r->status == HTTP_NOT_MODIFIED) {
apr_table_do((int (*)(void *, const char *, const char *))
form_header_field,
(void *) &h, r->headers_out,
"Connection",
"Keep-Alive",
"ETag",
"Content-Location",
"Expires",
"Cache-Control",
"Vary",
"Warning",
"WWW-Authenticate",
"Proxy-Authenticate",
NULL);
}
else {
apr_table_do((int (*) (void *, const char *, const char *))
form_header_field,
(void *) &h, r->headers_out, NULL);
}
It seems that only certain headers are sent on these responses, all
others are stripped. Is this a requirement of HTTP? Can anyone explain
why this is like this?
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: mod_headers and 304 Not Modified
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> It seems that only certain headers are sent on these [304] responses, all
> others are stripped. Is this a requirement of HTTP? Can anyone explain
> why this is like this?
A 304 response is supposed to send the minimum amount of information
necessary to indicate that that a cache should use its local data.
....Roy
Re: mod_headers and 304 Not Modified
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> > It seems that only certain headers are sent on these responses, all
> > others are stripped. Is this a requirement of HTTP? Can anyone explain
> > why this is like this?
>
> section 10.3.5 of RFC 2068 spells out exactly which heads SHOULD and
> SHOULD NOT, and MUST and MUST not be a part of a 304 response. It is very
> clear about some headers.
That was removed in RFC 2616. It is less specific now, but the intention
remains that only metadata likely to be needed by the cache may be sent.
....Roy
Re: mod_headers and 304 Not Modified
Posted by Graham Leggett <mi...@sharp.fm>.
rbb@covalent.net wrote:
> > It seems that only certain headers are sent on these responses, all
> > others are stripped. Is this a requirement of HTTP? Can anyone explain
> > why this is like this?
>
> section 10.3.5 of RFC 2068 spells out exactly which heads SHOULD and
> SHOULD NOT, and MUST and MUST not be a part of a 304 response. It is very
> clear about some headers. Which header values are you not seeing that you
> want to see?
Any header added by mod_headers.
Does the spec say specifically "these headers and no other", or does it
specify the behaviour for specific headers, but undefined for the rest?
If the second option, then it's a bug.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: mod_headers and 304 Not Modified
Posted by rb...@covalent.net.
On Tue, 22 May 2001, Graham Leggett wrote:
> (I'm reposting this, I think it fell through the cracks)
>
> rbb@covalent.net wrote:
>
> > > How about a new hook for adding AP_FTYPE_HTTP_HEADER filters?
> >
> > IMO, this should be fixed by adding the three filters above in a
> > core_insert_filter phase. Then, mod_headers can easily be run before the
> > core's insert_fitler phase. Problem solved.
>
> Trouble is - there is one last problem. mod_headers works great, but not
> on 304 Not Modified responses.
>
> The reason why is this bit of code in ap_http_header_filter():
>
> if (r->status == HTTP_NOT_MODIFIED) {
> apr_table_do((int (*)(void *, const char *, const char *))
> form_header_field,
> (void *) &h, r->headers_out,
> "Connection",
> "Keep-Alive",
> "ETag",
> "Content-Location",
> "Expires",
> "Cache-Control",
> "Vary",
> "Warning",
> "WWW-Authenticate",
> "Proxy-Authenticate",
> NULL);
> }
> else {
> apr_table_do((int (*) (void *, const char *, const char *))
> form_header_field,
> (void *) &h, r->headers_out, NULL);
> }
>
> It seems that only certain headers are sent on these responses, all
> others are stripped. Is this a requirement of HTTP? Can anyone explain
> why this is like this?
section 10.3.5 of RFC 2068 spells out exactly which heads SHOULD and
SHOULD NOT, and MUST and MUST not be a part of a 304 response. It is very
clear about some headers. Which header values are you not seeing that you
want to see?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------