Re: De Re If-Modified-Since

On Wed, 16 Aug 1995, Lou Montulli wrote:
> In article <Pine.SOL.3.91.950816222536.604K-100000@eat.organic.com> Brian
> Behlendorf <brian@organic.com> wrote:
> > Variables: IMS = If-Modified-Since date
> >            LM = Server's last-modified
> >            CURRTIME = The current time on the *server*
> > 
> > 1) if IMS < LM send document
> > 2) if IMS > CURRTIME send document
> >    that leaves LM < IMS < CURRTIME for the 304 response.
> 
> Brian you should go read the spec or past messages before you post 
> stuff like this.  As pointed out earlier in this thread the
> IMS time can be after the current last modified date of the file
> and still be valid.  Changing this is not an option.

Did you read the spec?  Check out: 
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.

> > > 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.  

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/

Received on Thursday, 17 August 1995 00:12:18 UTC