I've been setting both Cache-Control max-age and Expires. But I
noticed that remove_content_headers() only removes the
@entity_headers which only includes Expires.
Should remove_content_headers remove both?
--
Bill Moseley
moseley@hank.org
Bill Moseley
> I've been setting both Cache-Control max-age and Expires. But I
> noticed that remove_content_headers() only removes the
> @entity_headers which only includes Expires.
>
> Should remove_content_headers remove both?
I'm not sure. RFC 2616 section 4.5 starts out saying "There are a few
header fields which have general applicability for both request and
response messages, but which do not apply to the entity being
transferred." and Cache-Control is one of these. This implies that
remove_content_headers shouldn't touch it.
Does the current behaviour create a problem in your application?
--Gisle
On Wed, Jan 25, 2006 at 01:49:16AM -0800, Gisle Aas wrote:
> Bill Moseley
>
> > I've been setting both Cache-Control max-age and Expires. But I
> > noticed that remove_content_headers() only removes the
> > @entity_headers which only includes Expires.
> >
> > Should remove_content_headers remove both?
>
> I'm not sure. RFC 2616 section 4.5 starts out saying "There are a few
> header fields which have general applicability for both request and
> response messages, but which do not apply to the entity being
> transferred." and Cache-Control is one of these. This implies that
> remove_content_headers shouldn't touch it.
I'm not sure either. Expires and Cache-Control have somewhat similar
function (section 14.9.3 discusses what happens when both are
present) so I thought it odd that one would be removed and not the
other.
Like Expires, Cache-Control does describe what to do with the content
in a response, so would seem reasonable to consider it a content
header. On there other hand, I believe it's possible to include
Expires and Cache-Control on a 304 response that contains no content.
I'm not sure why Cache-Control isn't listed in 7.1 Entity Header
Fields, as Cache-Control can override Expires as noted in 14.21.
So, ya, I'm not sure.
> Does the current behaviour create a problem in your application?
Not really a problem. I have a response that includes Last-Modified,
Content-Length, Cache-Control max-age, and Expires. In some cases that
content is further processed and becomes non-cacheable. So I need to
remove all headers except Last-Modified (and even leaving
last-modified is questionable).
So I was trying to use remove_content_headers for a different
purpose, I suppose.
--
Bill Moseley
moseley@hank.org
On Wed, Jan 25, 2006 at 06:04:38AM -0800, Bill Moseley wrote:
> On Wed, Jan 25, 2006 at 01:49:16AM -0800, Gisle Aas wrote:
> > Bill Moseley
> >
> > > I've been setting both Cache-Control max-age and Expires. But I
> > > noticed that remove_content_headers() only removes the
> > > @entity_headers which only includes Expires.
> > >
> > > Should remove_content_headers remove both?
> >
> > I'm not sure. RFC 2616 section 4.5 starts out saying "There are a few
> > header fields which have general applicability for both request and
> > response messages, but which do not apply to the entity being
> > transferred." and Cache-Control is one of these. This implies that
> > remove_content_headers shouldn't touch it.
Another twist on this.
I test If-Modified-Since and on 304 responses call remove_content_headers().
That removes the Expires headers but leaves the cache-control max-age
header.
I noticed that in the web logs that firefox was making If-Modified-Since
requests on every page load for documents that should have been
cached.
In Firefox, it seems, if an Expires header is not returned in the 304
response then it continues to use its old Expires header (which is
obviously expired already). Opera, IE, and Safari seem to go ahead
and use the cache-control max-age setting to reset when to expire the
page.
rfc2616 says for 304 responses:
"The response MUST include the following header fields:"
...
- Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same
variant
Since the original 200 response included an Expires header, and since
the Expires headers should now be updated (the old date has past), it
would seem to be required in the 304 response. Agreed?
I'm not clear which behavior is correct when the Expires header is
missing. Without a cache-control max-age header it would seem to be
smart to continue to make the requests using If-Modified-Since since
the cache timeout has, well, expired. But if the response includes a
max-age setting, I'm not clear if the client should update when to
expire the page.
--
Bill Moseley
moseley@hank.org