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

And my replies:
    
    - I'd rather not require servers to generate opaque validators, though
      I do want to require clients and proxies to use them if present.

I currently have this as
   An HTTP/1.1 server MUST [XXX SHOULD?]  return a cache-validator
   value, which could be null, with every response.
(Actually, this should probably be "with every response to a cachable
method", which requires some additional definition.)  In other words,
I'm keeping it open as an item for discussion.

Could you provide some discussion of why servers should not be required
to generate opaque values?  And some indication of what a client should
do if a server doesn't provide one?  (Revert to GET I-M-S?)
    
    - In section 2.3, it says that there needs to be a clear definition of
      `correct' (I agree to that), but the section fails to give a clear
      definition.

I do give a definition; please explain what is unclear about it, or
suggest your own.
    
    - I have no big problem with clients using `stale-max=...' to override
      a lifetime set by the server, as long as the addition of stale-max
      does not mean that service authors loose their ability say that a
      response must really _never_ be served from a cache without
      validation (interactive web services often generate such responses,
      and no, they cannot do without them).

Here's my dilemma: we can specify ways for the server to override
the client's choice, and for the client to override the server's
choice.  When they disagree, who wins?  One could argue that since
the server is where the "application" is defined, if the server
absolutely insists on something, then the client must yield.  Or
one could argue that since this is all ultimately meant to keep
the users happy, that they need to remain in control.  I have
a slight leaning to one side of this argument, but I don't have
a strong justification for my leaning so I'd like to see what
other people think.
    
    - (2.11) If the warnings are in a response header, they should not use
      numbers from the Status-Codes space.
    
Why not?  I wasn't entirely sure I was doing the right thing here,
but I couldn't think of a reason against it and it seemed like a
good way to avoid confusion between numbering spaces.  I'm certainly
not insisting on using codes from the Status-codes space, but I'd
like to see a rationale for doing otherwise.

    - In `2.14 Side effects of GET and HEAD':
       | 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.
      This interpretation of 14.2 is completely incorrect.  Ever heard of 
      page counters?

Good point about page counters.  And yet, it's quite clear that
the draft 1.1 specification allows caching of GET and HEAD methods
unless the server specifies otherwise.  Is it OK if I change this
to be:
   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.
    
Anyway, the point of this paragraph (especially the last sentence)
was to try to make things more explicit.  Do you disagree with
that statement:
    We make this explicit: normally, GET and HEAD methods SHOULD NOT
    have side effects.
Should I replace "normally" with "unless the server explicitly
disables caching"?

-Jeff

Received on Tuesday, 9 January 1996 00:43:21 UTC