Re: Koen's comments on http://ftp.digital.com/%7emogul/cachedraft.txt

Jeffrey Mogul:
[...requiring headers not absolutelty necessary...]
>This is a similar misunderstanding as the one related to a cache's
>choice of a Fresh-until value where none is specified.
>
>Let me make it QUITE clear (since I have obviously failed to do so)
>that I am not trying to make any extra work for service authors.
>My expectation is that in almost all cases, the server implementor
>will choose a simple and unmodifiable algorithm for generating
>Cache-validator: values, and the service author (or system
>administrator will never have to think about them).

Extra work that can be automated is still extra work, because the
automation also takes work.  What guarantees can you give me that this
work will be done?  Again, let me repeat:
  
   I can't guarantee that the zero default collapse scenario outlined
   in my earlier message _will_ happen, but I see no justification for
   taking such a risk.

[...]
>So, to restate things as clearly as possible: NO SERVICE AUTHOR
>NEED EVER CARE ABOUT THIS.

I include special-purpose http server authors and CGI script authors
in the group of service authors, and they _will_ need to care.

[...]
>    >what [should] a client
>    >do if a server doesn't provide one?  (Revert to GET I-M-S?)
>    
>    Yes.
>
>I'm comfortable with this, as long as it is made an absolutely
>mandatory part of the specification that all HTTP/1.1 clients
>and caches completely and properly implement the opaque-validator
>mechanism.  That is, if the server does supply an opaque validator,
>then the clients and caches MUST use it instead of a Last-modified
>date (in order to claim compliance with HTTP/1.1).  If you'll agree
>to this requirement, I'd be willing to make it optional for servers
>to generate Cache-validator: headers.

I agree to that requirement.  Does this mean we now have consensus
that opaque validators are not required every 1.1 response?

[....]
>I think you're splitting hairs, but perhaps this version will please
>you:
>	Section 14.2 (``Safe Methods'') of the draft HTTP/1.1
>	specification[1] implies that GET and HEAD methods should not
>	have any side effects that would prevent caching the results of
>	these methods, unless the origin server explicitly prohibits
>	caching. 
[....]

I feel we are going around in circles.  I still think this is an
incorrect interpretation, and by previous statement about 14.2 side
effects being orthogonal to caching still apply to your new version.

>-Jeff

Koen.

Received on Wednesday, 10 January 1996 09:08:31 UTC