Re: Comments (Part 2) on HTTP I-D Rev 05

"Adams, Glenn" <gadams@spyglass.com> writes:

>54. Throughout the whole of section 13 it is often unclear as to
>whether a requirement or statement is meant to apply only to a proxy
>cache, to a user agent cache, or to both.

There's a third class to consider as well, although I don't know of any
examples to cite: the origin-server cache.  While a proxie cache has a
combined client and server, an origin-server cache would not have a
client component (or at least not in use in a given transaction).

>64. Section 13.2.3, 3rd para., has "HTTP/1.1 requires origin servers to
>send a Date header, if possible, with every response ..." seems to be
>stating a conditional imperative. Rather than paraphrasing section
>14.18 and possibly confusing the requirements regarding Date header
>transmission, I'd suggest rephrasing this to simply refer to a Date
>header, if present, and to state what must be done in the case that a
>Date header is not present.

Good point.

>65. Section 13.2.3, pg. 76, 1st para. after pseudo code block, has "the
>server MUST"; suggest changing to "the proxy server MUST".

While this isn't my forte, I believe the text is correct, as it applies
to all server-caches, not just proxy-caches.

>74. Section 13.5.1, pg. 84, 1st para, 1st bullet, has "End-to-end
>headers which MUST be ...". The use of MUST and SHOULD keywords in
>relative clauses is problematic and should be avoided since it does not
>state a requirement per se.

I don't understand your meaning of "relative clauses", however this case
in particular does state a requirement, that intermediaries forward
end-to-end headers to the ultimate recipient.  This requirement isn't
stated anywhere else in the document, and must be retained.

>78. Section 13.5.3, pg. 86, 5th para., has "all such old headers are
>replaced." which sounds like a requirement: "... MUST be replaced."

The requirement is already stated two paragraphs prior to the citation:

   "Unless the cache decides to remove the cache entry, it MUST also
   replace the end-to-end headers stored with the cache entry with
   corresponding headers received in the incoming response."

>82. Section 14, pg. 91: suggest adding a sentence to each header
>defined by this section that states whether the header is end-to-end or
>hop-by-hop and whether the header is cachable by default, cachable by
>explicit cache directive, or never cachable.

While that would clear up some confusion, I believe the document already
contains too much duplication, and duplicated information always runs the
risk of becoming contradictory due to modification over time.

>93. Section 14.9, pg. 99, 1st para., has "When a directive appears
>without any 1#field-name parameter, the directive applies to the entire
>request or response." At the present, no cache-request-directive
>employs a 1#field-name parameter (see pg. 98); consequently all request
>directives apply to the entire request in all cases.

True, however the text establishes a rule for all Cache-Control
directives, now and in the future.

Ross Patterson
VM Software Division
Sterling Software, Inc.

Received on Monday, 9 November 1998 10:17:25 UTC