W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Re: comments on HTTP/1.1 Rev02 20Feb98

From: Jim Gettys <jg@pa.dec.com>
Date: Wed, 11 Mar 1998 17:53:44 -0800
Message-Id: <9803120153.AA23883@pachyderm.pa.dec.com>
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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:13 EDT