Re: Improving If-Modified-Since

In article <19950817.77E12D0.23E6@contessa.phone.net> mwm@contessa.phone.net
(Mike Meyer) wrote:
> 
> > This would work pretty well but has the disadvantage of not being
> > reproducable on the client end.
> 
> The IMS LM date has the same problem - the client can't reproduce it.
> 
> I like the more generic "If-different" header. We can even tweak it to
> save 15 of the 20 bytes you complained about:
> 
>         If-Different: 1#( field-name value ; )
> 
> The server then verifies that for each field-name/value pair, it is
> going to send a header with that name whose value (after trimming
> leading and trailing whitespace) is the same as the client sent on the
> if-different field. If one of them is different it sends the document.
> Otherwise, it sends a 3xx reply "Not different".
> 
> You can therefore get the behavior you want from
> 
>         if-modified-since: last-modified ; size=length
> 
> with
> 
>         if-different: last-modified ; content-length length
> 
> and leave if-modified-since with the current definition for those who
> have a use for that.
> 

The if-different header would occomplish this, but still think it's
wasteful.  We should try and use the existing IMS header if
possible.  If it turns out not to be possible then we should add
to the future specification that all http headers can be followed
by one or more arguments delimited by semi-colons.  This will
keep this lossage from happening in the future.

Other than that I'm happy with this proposal.  Let's keep the
names short and get this into some form of a spec so that we
can get on with life.  (not that it hasn't been fun arguing)

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

Received on Thursday, 17 August 1995 02:42:58 UTC