I have been selected as the Applications Area Directorate reviewer
for this draft (for background on APPSDIR, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document
shepherd or AD before posting a new version of the draft.
Document: draft-ietf-httpbis-p1-messaging-24
Title:
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
Reviewer: S. Moonesamy
Review Date: October 27, 2013
IETF Last Call Date: October 21, 2013
Summary: This draft is almost ready for publication as a Proposed Standard.
This document provides an overview of HTTP architecture and its
associated terminology, defines the "http" and "https" Uniform
Resource Identifier (URI) schemes, defines the HTTP/1.1 message
syntax and parsing requirements, and describes general security
concerns for implementations.
The document is well-written and clear. I did not verify the changes
between this specification and RFC 2616 as the intended status is
Proposed Standard. This specification can affect other
specifications in the Applications Area as there are several
specifications which are built upon HTTP.
Major issues: None
Minor issues:
In Section 2.6:
"Intermediaries that process HTTP messages (i.e., all intermediaries
other than those acting as tunnels) MUST send their own HTTP-version
in forwarded messages. In other words, they MUST NOT blindly forward
the first line of an HTTP message without ensuring that the protocol
version in that message matches a version to which that intermediary
is conformant for both the receiving and sending of messages."
The first RFC 2119 requirement (see above) states that the
intermediary has to send its own HTTP-version while the second RFC
2119 requirement prohibits the intermediary from blindly forwarding
the first line of the HTTP message. The intent of the first
requirement seems clear to me. I suggest having the second
requirement as clarifying text instead of a RFC 2119 requirement.
"A client SHOULD send a request version equal to the highest version
to which the client is conformant and whose major version is no
higher than the highest version supported by the server, if this is
known."
The client would have to track the version supported by the server
once it knows that information. A server can be one or more HTTP
implementations. In practice these implementations will likely
support HTTP 1.1. I'll list the "and whose major version is no
higher than the highest version supported ..." as an issue. Is the
intent to ensure that the client can work with HTTP 2.0?
"A server MAY send a 505 (HTTP Version Not Supported) response if
it cannot send a response using the major version used in the
client's request."
Why is this a RFC 2119 "may"?
In Section 5.7:
"An intermediary MUST NOT forward a message to itself unless it is
protected from an infinite request loop. In general, an intermediary
ought to recognize its own server names, including any aliases, local
variations, or literal IP addresses, and respond to such requests
directly."
I don't understand why an intermediary would forward a message to
itself. Please note that I do not consider this prohibition as an issue.
In Section 6.1:
"Recipients that trigger certain connection behavior based on the
presence of connection options MUST do so based on the presence
of the connection-option rather than only the presence of the
optional header field. In other words, if the connection option
is received as a header field but not indicated within the
Connection field-value, then the recipient MUST ignore the
connection-specific header field because it has likely been
forwarded by an intermediary that is only partially conformant.
I am flagging the usage of a requirement followed by the "must
ignore" requirement as an issue as the "in other words" suggest that
it is a clarification of the first requirement.
In Section 6.4
"A client SHOULD limit the number of simultaneous open connections
that it maintains to a given server."
There is an explanation about why a specific number is not included
for this recommendation in the paragraphs following the above
text. I read Issue #131. I don't see any discussion of the
tradeoffs in Section 6.4. The is a note about servers may reject an
excessive number of connections from a client if they deem that it is abusive.
The HTTP Transfer Coding namespace (Section 8.4) is currently "First
Come First Served". The new registration procedure required IETF
Review. What is the reason for the change?
In Section 8.5.1:
'The registration SHOULD name a set of expected "protocol-version"
tokens associated with that token at the time of registration.'
Why is this a RFC 2119 "should"?
"The IESG MAY reassign responsibility for a protocol token. This
will normally only be used in the case when a responsible party
cannot be contacted."
I suggest using plain English instead of RFC 2119 key words for the
above (and for the rest of the text in Section 8.5.1).
Nits:
For Section 8.1, the Message Header Field Names registry is at
http://www.iana.org/assignments/message-headers/
For Section 8.2, the URI Schemes registry is at
http://www.iana.org/assignments/uri-schemes/
In Section 8.4, the RFC 2119 key words are not needed as that section
is about a procedure for registration. Plain English is usually clear enough.
Regards,
S. Moonesamy