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