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

Glenn Adams <> writes:

>4. Section 2.2, pg. 16, definition of "CTL", fails to consider that
>ASCII (and ISO646-1993) consider SPACE (040) to be a control character
>of the same status as DEL (177).

Perhaps, but HTTP and the Internet documents its BNF derive from have
always treated SP as a special case, differing from most of the CTLs in
that it has properties of its own (as do CR, HT, and LF).

>15. Section 3.9 refers to "short 'floating point' numbers". I would
>suggest this with "real numbers" since both "short" and "floating
>point" seems to implementation specific.

And as has been mentioned on this list before, these are actually
fixed-point numbers.

>17. Section 4.2, pg. 31, 4th para., states "It MUST be possible ...". I
>would suggest replacing this with a statement that uses the converse using the
>form "MUST NOT ... unless ..."; e.g., "Multiple header fields MUST NOT be
>combined into one header unless ...".

Sorry, that changes the meaning entirely.  This paragraph expresses the
header-combination rule, which allows q receiving party to combine
multiple instances of the same header-name by appending the values of
those headers in order and separated by commas.  This behavior is
actually required by the CGI 1.1 specification for passing headers to
CGI programs as CGI variables.  Your rewrite places the restriction on
the receiver, not the sender (where it rightly belongs).  A "MUST NOT"
rewrite should look more like this:

   "Header fields which are not defined in their entirety as a
   comma-separated list [i.e., #(values)] MUST NOT be appear more
   than once in a message"

Still, I find the existing text to be clearer and more to the point.

>18. Section 4.3, pg. 31, 5th para., states "The presence of a message-body
>in a request is signaled by the inclusion of Content-Length or Transfer-
>Encoding header field ...".  However, "multipart/byte-ranges" may include
>a message-body without either of these headers.

The document generally treats "multipart/byteranges" as appropriate only
for responses, however you are correct that if someone finds a use for
it in requests there is a contradiction.

>22. Section 4.4, pg. 32, 5th para., states "HTTP/1.1 user agents MUST
>notify the user when an invalid length is received and detected." This
>does seem to be reflected by current industry practice (cf. IE4 and
>Netscape Communicator 4 behavior). If this standard is intended to capture
>current practice, then this is a broadening of current practice. I'd suggest
>using the keyword "MAY" instead.

RFC 1945 (HTTP 1.0) was a "document current practices" excercise.  HTTP
1.1 places new requirements on implementations, and not all deployed
HTTP 1.1 implementations are currently correct.

Put differently, "Mosaic and httpd defined HTTP 1.0, the IETF defined
HTTP 1.1". ;-)

>30. Section 9, pg. 48, 2nd para., appears to be partially redundant with
>Section 5.1.2, pg. 35, line 2078 (in file). Furthermore, does this requirement
>actually hold for forms of Request-URI other than abs_path? For example,
>does an OPTIONS * HTTP/1.1 request require a Host header?

Yes, Host is required on every HTTP 1.1 request, even for "OPTIONS *".
For example, this allows an origin server to respond differently
depending on whether the Host header refers to "WWW.A.Com" or "WWW.B.Org".

Ross Patterson
VM Software Division
Sterling Software, Inc.

Received on Monday, 9 November 1998 11:20:29 UTC