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

comments on HTTP/1.1 Rev02 20Feb98

From: Dave Kristol <dmk@research.bell-labs.com>
Date: Tue, 24 Feb 98 11:01:00 EST
Message-Id: <9802241601.AA07737@aleatory.tempo.bell-labs.com>
To: http-wg@cuckoo.hpl.hp.com
Cc: jg@w3.org
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5389
First:  the alphabetized index is fantastic.  Thanks!!

These comments apply to the Rev-02 draft, 20 Feb 1998, available off
<http://www.w3.org/Protocols/HTTP/Issues/>.  I've divided my remarks
below into possible issues, nits, and nitty nits.

Dave Kristol
Possible Issues

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?

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?

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.)

5) 14.8 Authorization
    "HTTP access authentication is described in section 11."
    Not anymore, it isn't!  At least, not in any detail.

6) 14.9 Cache-Control
    I have three editorial suggestions to the reference utility of the

    1) It would be nice if the various cache-control directives were
    in the document's index.

    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.

    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.

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.

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

2) 8.1.1
    "often require[s] a client to make"
    		   ^-> add
    "Analys[i]s of these..."
            ^-> change

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 :-)

4) 10.3, Redirection 3xx
    "A client SHOULD implement detect infinite..."
    		     --------- -> delete

5) 10.3.6, 305 Use Proxy
    "Note: ... a single request, or [to be] generated by..."
    				     ----- -> add
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

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

8) 12.3, Transparent Negotiation (last paragraph)
    "... does not prevent any such mechanism from being developed as an
    extension [that could be] used ..."
    	       ============= -> change
9) 13.1.2, Warnings
    "2. ... entity headers that [is] not rectified by a revalidation[,]"
				 == -> change			  <- =
    [Verb refers back to "aspect".]

10) 13.2.1 Server-Specified Expiration
    [last sentence]
    "See section 13.13 for [an] explanation of ..."
    			    -- -> add
11) 13.2.3, Age Calculations
    "Because of network-imposed delays, some significant interval may
    pass [between] the time ...
	  ======= -> change

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 ..."

13) 14.3, Accept Encoding
    [first line]
    " ... but restricts the content-coding[s] ..."
    					   ^- add

14) 14.9.3, Modifications of ...
    "If a response includes a[n] s-maxage directive, ..."
    			      ^- add

    " ... and the fact that [pre]-HTTP/1.1-compliant caches ..."
    			     --- -> change (from "non"; "non" would
				     also apply to HTTP/1.2)

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.

    Next paragraph:  "private""
    			      ^- delete (at least)

16) 14.16, Content-Range
    "... unless this length [this] is unknown ..."
    			     ---- -> delete

    "If the server ignores a byte-range-spec because ..."
			     --------------- -> should this be Courier?

17) 14.23, Host
    "... servers MUST respond with a 400 [(Bad Request)] status code ..."
    					  ------------- -> 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.

	[in two places]
		  "... for other header fields than Content-MD5" ->
		  "... for header fields other than Content-MD5"

19) 14.44, Vary
    [3rd paragraph]
    "... for the duration of time [for] which the response is fresh."
    				   === -> change

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."

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."

22) 15.3, DNS Spoofing
    "... the deliberate mis[s]-association of ..."
    			    ^- delete

23) 15.6, Authentication Credentials...
    "dicard" -> "discard"
    "enourage" -> "encourage"

24) 17, References
    [38] ... RFC 2279 [(]obsoletes RFC 2044), ...
    		       ^- add

25) 19.4.4, Introduction of Content-Encoding
    "... to perform [a function equivalent to] Content-Encoding."
    		     ======================== ->
		     change from "an equivalent function as"

26) 19.4.7, MHTML ...
    "... including line length limitations an[d] folding, ..."
    					      ^- add

27) 19.5.1, Content-Disposition
    "... seem to be present in the filename-parm parameter, ..."
    Should be Courier typeface?

28) 19.6, Compatibility ...
    "It is worth noting that[,] at the time of composing this specification, we ..."
    			     ^- add

    "... described in section"
    That's 19.6.2 now, I think.

29), Changes to Simplify ...
    "... allocation of many IP addresses to a single host created serious
    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."

    [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."

30), Significant Changes From ...
    "Require proxies [to] upgrade requests ..."
    		      -- -> add

    "The Cache-Control: max-age directive [was] not properly defined..."
    					   --- -> add

    "A new error code (416)[ ] was needed to indicate an error for a byte
    			    ^- add
    range request [that falls] outside..."
    		   ---------- -> add

    [Last paragraph]
    Is it transfer *encoding* or transfer *coding*?

    "... The solution is [that] transfer codings become..."
    			  ---- -> change

    "... and enables trailer headers in the future." ->
    "... and enabling headers in the trailer in the future."

31), Clarifications of the Specification
    two instances of "t-specials" should be "tspecials".

    "Fix chunked transfer [en]coding to allow..."
    			   -- -> delete
Nitty nits

1) 10.2.7, 206 Partial Content
    "...indicating the desired range , and...
    				    ^- delete

2) 15.1.3, Encoding Sensitive Information in URL's
    [last sentence]
    "Servers can use POST[-]based form submission instead[.]"
    			  ^- add			  ^- add
Received on Tuesday, 24 February 1998 08:05:03 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC