- From: Dave Kristol <dmk@research.bell-labs.com>
- Date: Tue, 24 Feb 98 11:01:00 EST
- To: http-wg@cuckoo.hpl.hp.com
- Cc: jg@w3.org
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
spec.
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.
==================================
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.
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 19.6.2.0."
That's 19.6.2 now, I think.
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."
[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) 19.6.3.1, 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) 19.6.3.2, 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