Strict date equality for If-Modified-Since comparison?

Brice Figureau brice+nginx at daysofwonder.com
Wed Aug 15 21:19:44 MSD 2007


On Wed, August 15, 2007 17:35, Igor Sysoev wrote:
> On Wed, Aug 15, 2007 at 05:13:36PM +0200, Brice Figureau wrote:
>
>> After a few tests of unsuccessful attempts to trigger a 304 with nginx
>> 0.6.1 with If-Modified-Since, I thrown an eye to the source...
>
> Have you tried in browser ?

No, that was by hand... I was just checking if a file was modified on my
servers...

I know that browsers usually are using the Last-Modified tag they got
first when they cached the entity.

>> >From my understanding nginx returns a 304 only if If-Modified-Since
>> matches exactly Last-Modified.
>>
>> Apache is more liberal and returns a 304 for any date greater or equals
>> than the last-modified.
>>
>> Is-it not too strict?
>>
>> I know that RFC2616 (section 14.25) adds a note about comparison and
>> does
>> not enforce any specific methods...
>
> I prefer to use Last-Modified as tag.

Actually, that's not really true as you are converting the IMS to unix
timestamp for the comparison with the file mtime.

Using LM as a tag would have mean converting the file mtime to a date
string and perform a pure string comparison, this would have retained the
full "opaqueness" of the IMS/LM...

> The browsers remember LM and then use this value in IMS requests.

Yes, I know that it is usually how it works with regular browsers, but
that might not be the case with tools like curl/wget since the downloaded
file mtime might not be equals to the server LM.
In which case using 'now' unconditionally would work with Apache but not
nginx.

Anyway, that's not an important issue :-)
Maybe you could add a nginx config settings?
-- 
Brice Figureau
Days of Wonder






More information about the nginx mailing list