durusmail: quixote-users: Re: Augmenting StaticFile to use "Expires:"
Augmenting StaticFile to use "Expires:"
2003-05-31
2003-05-31
2003-06-02
Jason Sibre (3 parts)
Re: Augmenting StaticFile to use "Expires:"
2003-06-21
2003-06-21
2003-06-23
Re: Augmenting StaticFile to use "Expires:"
2003-07-15
Re: Augmenting StaticFile to use "Expires:"
Graham Fawcett
2003-06-21
Neil Schemenauer wrote:
> Hi Jason,
>
> I think supporting the If-Modified-Since header would be a good idea.
> However, we need to be careful about being compliant with the HTTP 1.1
> specification.  We are probably not right now but we should be and I
> don't want to make things worse.  I'm not saying there is something
> specifically wrong with your patch, I'm just being cautious.

It's a very good point, Neil. As I read the spec, I think we are compliant, but
we're not following the suggestions.

Fortunately, the specified algorithm for the If-Modified-Since header is
mercifully short. The two key points (IMO) that we haven't implemented are (a)
the recommendation for using exact date-string matches (as you suggested), and
(b) the point that Range headers (if present) should be honoured in a non-304
response to a conditional GET. But the latter point isn't relevant, since
there's no Range support in Quixote at this time.

> I would prefer to only support exact matches for the If-Modified-Since
> header.  That makes the code simpiler and more robust.  User agents are
> not supposed to mangle the Last-Modified date.  Does anyone have an
> objection to only supporting exact matches?

It's an excellent idea, and in line with the specification:  "To get best
results when sending an If-Modified-Since header field for cache validation,
clients are advised to use the exact date string received in a previous
Last-Modified header field whenever possible."  (sec. 14.25)

> Adding a Last-Modified header when serving static files is definitely a
> good idea.  I think that should probably be enabled by default.
>
>   Neil

If Jason doesn't beat me to it ;-) I'd be willing to submit a patch for the
exact-datestring match behaviour.

-- Graham



reply