- From: Jim Gettys <jg@pa.dec.com>
- Date: Wed, 11 Mar 1998 17:53:44 -0800
- To: Dave Kristol <dmk@research.bell-labs.com>
- Cc: http-wg@cuckoo.hpl.hp.com
Thanks as usual for your excellent read!
> From: dmk@research.bell-labs.com (Dave Kristol)
> Date: Tue, 24 Feb 98 11:01:00 EST
> To: http-wg@cuckoo.hpl.hp.com
> Cc: jg@w3.org
> Subject: comments on HTTP/1.1 Rev02 20Feb98
>
>
> 1) 9.2 OPTIONS
> "The response body, if any, SHOULD also include...."
>
> The spec. says the body itself is undefined. Can we at least state
> what the media type is?
>
My memory is that the media type is deliberately left undefined for later
use. I can anticipate a number of possible media types that might make
sense, including an HTML page that just explains to a user what the options
might be.
> 2) 10.2.7, 206 Partial Content
> "... the Content-Length header field in the response MUST match..."
>
> Is there some reason why the entity couldn't be sent with chunked
> transfer coding instead and *without* a Content-Length?
>
> It wasn't clear to me, until sect. 19.6.3, that a server could
> *limit* itself to sending these headers in response to If-Range.
> Could we make that clearer?
Dealt with in Jeff's message
http://www.ics.uci.edu/pub/ietf/http/hypermail/1998q1/0390.html (added
to issue CONTENT-LENGTH).
>
> 3) 13, Caching in HTTP
> Last paragraph: I think something like the following needs to be
> added at the end:
> "In such cases, the design should also provide a way to inform the
> end user of a break in transparency."
>
> 4) 13.11 Write-Through Mandatory
> Suppose I want to add a custom method to HTTP, one of whose
> side-effects would be to invalidate a cache entry. (Suppose
> I were adding something comparable to DELETE, for example.)
> How would the cache know it must invalidate the associated
> resource? I don't think any of the Cache-Control directives
> can tell the cache to discard an entry, can they? (And if they
> could, that would be an interesting denial of service attack.)
>
Already dealt with in the thread with Jeff Mogul.
> 5) 14.8 Authorization
> "HTTP access authentication is described in section 11."
> Not anymore, it isn't! At least, not in any detail.
I've fixed the reference to point to the authentication document, here,
and in other places where a similar problem occurs.
>
> 6) 14.9 Cache-Control
> I have three editorial suggestions to the reference utility of the
> spec.
>
> 1) It would be nice if the various cache-control directives were
> in the document's index.
>
They are in the index: under Cache-Control, strangely enough :-).
> 2) It would be nice if each of the c-c directives had its own
> paragraph, similar to public/private/no-cache in 14.9.1. The
> hanging indents make it real easy to find descriptions.
Thanks for the suggestion; I hope you like the new formatting... I think
this is a good idea.
>
> 3) Provide a very short description (one sentence would be nice)
> for each of the c-c directives just to give the sense of what each
> one does. With each one I'd also like a list of the sections under
> 14.9 where the details could be found.
No to the first request, but I've added section cross references in the
BNF for the directives to help you find them more easily.
>
> 7) 14.39 TE
> Isn't the wording of the Note backwards? Shouldn't it be:
>
> "Note: Because of backward compatibility considerations with RFC
> 2068, neither parameter nor accept-params can be used with the
> "chunked" transfer-coding.
Yup.
> ==================================
> Nits
>
> 1) 2.1, implied *LWS
> I would feel better if "... between any two tokens" made it clear
> we're talking about the grammatical non-terminal "token". In
> compiler-speak, ';' is also a token, but that's not what's meant
> here.
Dunno quite what you want here....
>
> 2) 8.1.1
> "often require[s] a client to make"
> ^-> add
> "Analys[i]s of these..."
> ^-> change
>
Done
> 3) 8.2.4, Requirements for HTTP/1.1 clients
> "... the client should not wait for a[n indefinite or] lengthy period" ->
> --------------- -> delete
> ("indefinite" qualifies already as lengthy :-)
Done
>
> 4) 10.3, Redirection 3xx
> "A client SHOULD implement detect infinite..."
> --------- -> delete
Done
>
> 5) 10.3.6, 305 Use Proxy
> "Note: ... a single request, or [to be] generated by..."
> ----- -> add
Done
> 6) 11, Access Authentication
> "HTTP provides a several optional challenge-response authentication
> ^-> delete
> mechanisms which MAY be used ..."
> ^-> add
>
> "The general framework for access authentication, and the specifications
> --- -> add <- -
> of "basic" and "digest" authentication, are specified ..."
> ^-> add
>
Done
> 7) 12.1, Server-driven Negotiation
> "The Vary header field can be used to express the parameters
> [the server uses] to select a representation that is subject to ..."
> ================ -> change ------- -> add
>
Done
> 8) 12.3, Transparent Negotiation (last paragraph)
> "... does not prevent any such mechanism from being developed as an
> extension [that could be] used ..."
> ============= -> change
Done.
> 9) 13.1.2, Warnings
> "2. ... entity headers that [is] not rectified by a revalidation[,]"
> == -> change <- =
> [Verb refers back to "aspect".]
Done
>
> 10) 13.2.1 Server-Specified Expiration
> [last sentence]
> "See section 13.13 for [an] explanation of ..."
> -- -> add
Done
> 11) 13.2.3, Age Calculations
> "Because of network-imposed delays, some significant interval may
> pass [between] the time ...
> ======= -> change
Done.
>
> 12) 13.2.4, Expiration Calculations
> "If neither Expires nor Cache-Control: max-age or s-maxage ..." ->
> "If none of Expires, Cache-Control: max-age, or Cache-Control: s-maxage ..."
Done.
>
> 13) 14.3, Accept Encoding
> [first line]
> " ... but restricts the content-coding[s] ..."
> ^- add
>
Done
> 14) 14.9.3, Modifications of ...
> "If a response includes a[n] s-maxage directive, ..."
> ^- add
Done
>
> " ... and the fact that [pre]-HTTP/1.1-compliant caches ..."
> --- -> change (from "non"; "non" would
> also apply to HTTP/1.2)
Done
>
> 15) 14.9.6, Cache Control Extensions
> Third paragraph beginning "For example, ..."
> [Style] In this paragraph, the items in double-quotes, community,
> private, UCI, would appear elsewhere in Courier typeface and
> without quotes. Be consistent.
Hobgoblins of small minds :-).
>
> Next paragraph: "private""
> ^- delete (at least)
>
Done
> 16) 14.16, Content-Range
> "... unless this length [this] is unknown ..."
> ---- -> delete
>
Done
> "If the server ignores a byte-range-spec because ..."
> --------------- -> should this be Courier?
Done
>
> 17) 14.23, Host
> "... servers MUST respond with a 400 [(Bad Request)] status code ..."
>
Done
------------- -> add
>
> 18) 14.39, TE
> 14.40, Trailer
> [Style] "chunked" is rendered three different ways to mean the
> same thing
> - chunked (Roman, no quotes)
> - "chunked" (Roman, double quotes)
> - "chunked" (Courier, double quotes)
>
> Pick one and use it consistently.
More hobgoblins :-). Done.
>
> [in two places]
> "... for other header fields than Content-MD5" ->
> "... for header fields other than Content-MD5"
>
Done
> 19) 14.44, Vary
> [3rd paragraph]
> "... for the duration of time [for] which the response is fresh."
> === -> change
Done
>
> 20) 14.46, Warning
> [next-to-last paragraph after 299]
> "... the sender MUST include a warn-date in each warning-value."
> ->
> "... the sender MUST include in each warning-value a warn-date that
> matches the date in the response."
>
Done
> 21) 15.1, Personal Information
> [last sentence, reword as follows]
> "History shows that errors in this area often create serious
> security and/or privacy problems and generate highly adverse
> publicity for the implementer's company."
>
Done
> 22) 15.3, DNS Spoofing
> "... the deliberate mis[s]-association of ..."
> ^- delete
>
Done
> 23) 15.6, Authentication Credentials...
> "dicard" -> "discard"
> "enourage" -> "encourage"
>
Done
> 24) 17, References
> [38] ... RFC 2279 [(]obsoletes RFC 2044), ...
> ^- add
>
Done
> 25) 19.4.4, Introduction of Content-Encoding
> "... to perform [a function equivalent to] Content-Encoding."
> ======================== ->
> change from "an equivalent function as"
Done
>
> 26) 19.4.7, MHTML ...
> "... including line length limitations an[d] folding, ..."
> ^- add
>
Done
> 27) 19.5.1, Content-Disposition
> "... seem to be present in the filename-parm parameter, ..."
> -------------
> Should be Courier typeface?
>
Done
> 28) 19.6, Compatibility ...
> "It is worth noting that[,] at the time of composing this specification, we ..."
> ^- add
>
Done, but also added (1996) to make it clearer these recommendations may
become stale.
> "... described in section 19.6.2.0."
> That's 19.6.2 now, I think.
>
Done.
> 29) 19.6.1.1, Changes to Simplify ...
> "... allocation of many IP addresses to a single host created serious
> problems."
> I think we need to be more specific. How about:
>
> "... allocation of many IP addresses to a single host unnecessarily
> depleted the IP address space at a time when the community feared
> address space exhaustion."
No, a bigger problem is the routing problems rather than address space
exhaustion. (Think about adding the 257th virtual host on a server, when
your subnet has 256 addresses, for example).
I think leaving it as it is now is enough said, because the explanation
gets much too involved.
>
> [Bullet list]
> "Host request-headers are required in HTTP/1.1 requests."
> change to
> "A client that sends an HTTP/1.1 request MUST send a Host header."
Done.
>
> 30) 19.6.3.1, Significant Changes From ...
> "Require proxies [to] upgrade requests ..."
> -- -> add
Done.
>
> "The Cache-Control: max-age directive [was] not properly defined..."
> --- -> add
>
Done
> "A new error code (416)[ ] was needed to indicate an error for a byte
> ^- add
> range request [that falls] outside..."
>
Done
---------- -> add
>
> [Last paragraph]
> Is it transfer *encoding* or transfer *coding*?
>
Transfer coding
> "... The solution is [that] transfer codings become..."
> ---- -> change
>
Done
> "... and enables trailer headers in the future." ->
> "... and enabling headers in the trailer in the future."
>
Done
> 31) 19.6.3.2, Clarifications of the Specification
> two instances of "t-specials" should be "tspecials".
>
Done
> "Fix chunked transfer [en]coding to allow..."
> -- -> delete
Done
> ==================================
> Nitty nits
>
> 1) 10.2.7, 206 Partial Content
> "...indicating the desired range , and...
> ^- delete
Done
>
> 2) 15.1.3, Encoding Sensitive Information in URL's
> [last sentence]
> "Servers can use POST[-]based form submission instead[.]"
> ^- add ^- add
Done
Thanks again for your read!
- Jim
Received on Wednesday, 11 March 1998 17:55:30 UTC