Re: De Re If-Modified-Since

In article <Pine.SOL.3.91.950816235241.604L-100000@eat.organic.com> Brian
Behlendorf <brian@organic.com> wrote:
 http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-v10-spec-02.html#If-Modified-Since
> 
> | A conditional GET method requests that the identified resource be
> | transferred only if it has been modified since the date given by the
> | If-Modified-Since header. The algorithm for determining this includes
> | the following cases:
> 
> | a) If the request would normally result in anything other than a 200
> |    (ok) status, or if the passed If-Modified-Since date is invalid, the
> |    response is exactly the same as for a normal GET.
> 
> Check out "if the passed If-Modified-Since date is invalid".  I don't
> know any sane server author who would consider a date of Last-Modified
> after the current server date as "valid", but I suppose that is a matter
> of webmaster opinion (and thus server config?)  I would certainly
> consider it invalid, just as I would consider If-Modified-Since: Uranus
> invalid.

Well that's how I interpreted it as well, but several people
responded over the last couple of days that it was the intention
of the spec to accept any date equal to or past the current
modification date of the file.

> 
> > > > Your "solution" also fails when the file has been modified but
> > > > has the same date.
> > >
> > > Can we just agree (feel like rodney king here) that this is a broken case
> > > and not worth wasting time on?  Modified files can also have the same
> > > size, even the same checksum if we try hard enough.
> 
> > No, I'm afraid we can't.  Not when it is as easy to solve as
> > sending a length along with the IMS request.
> 
> In the end, you're right, this is a trivial thing to add to the protocol.
> And in the end, as a server-side guy, it doesn't affect what I do unless I
> want to use that info.  But that's not the only criteria involved when
> analysing proposals, is it?
> 
> As an attempt to reach common ground, I will say that I think the
> proposal floated about a generic If-Modified-<any response header> header
> might be a good idea.  Thus, you can have If-Modified-Content-Length if
> you want.

Making it a separate header adds 20 characters to the request that
would not be needed if "; length=" were sent instead.  We should
use the standard MIME method of extending headers by using semi-colon
delimited name value pairs.

:lou
-- 
Lou Montulli                 http://www.mcom.com/people/montulli/
       Netscape Communications Corp.

Received on Thursday, 17 August 1995 00:26:56 UTC