Subject: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p1-messaging-24

From: S Moonesamy <[email-masked]>
Date: Sun, 27 Oct 2013 11:44:46 -0700

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 27 Oct 2013 22:18:06 +0100

On 2013-10-27 19:44, S Moonesamy wrote:
> ...
> ...

Ack.

Out of curiosity: is there an obvious way to find out what the 
"canonical" URI of a registry is?

Best regards, Julian

---

From: S Moonesamy <[email-masked]>
Date: Mon, 28 Oct 2013 02:06:16 -0700

Hi Julian,
>"canonical" URI of a registry is?

There was a comment from IANA about its intention to keep 
http://www.iana.org/assignments/example format working.  The obvious 
way is to drop the file name and extension (e.g. 
http://www.iana.org/assignments/uri-schemes ).

Regards,
S. Moonesamy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Oct 2013 16:53:28 +0100

> Review.  What is the reason for the change?

My understanding is that we wanted to set a high bar because this really 
ought to happen with lots of care and review.

The related ticket is 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/188>, and it was 
discussed during IETF 75 
(<http://tools.ietf.org/wg/httpbis/minutes?item=minutes75.html>).

Best regards, Julian

---

From: S Moonesamy <[email-masked]>
Date: Mon, 28 Oct 2013 09:55:10 -0700

Hello,

While I was reviewing other drafts in the set I noticed that Section 
3.2.4 of draft-ietf-httpbis-p1-messaging-24 has the following:

   "Historically, HTTP header field values could be extended over
    multiple lines by preceding each extra line with at least one space
    or horizontal tab (obs-fold).  This specification deprecates such
    line folding except within the message/http media type
    (Section 8.3.1).  A sender MUST NOT generate a message that includes
    line folding (i.e., that has any field-value that contains a match to
    the obs-fold rule) unless the message is intended for packaging
    within the message/http media type."

There is an IETF specification which interpreted Section 4.2 of RFC 
2616 as follows:

   "the HTTP header syntax allows extending single header values across
    multiple lines, by inserting a line break followed by whitespace"

I'll classify deprecating line folding as an issue.

Section 4.2 of RFC 2616 (and RFC 2068) follows the same generic 
format as that given in Section 3.1 of RFC 822.  Section 2.2 of RFC 
2616 states that:

   "HTTP/1.1 header field values can be folded onto multiple lines if the
    continuation line begins with a space or horizontal tab."

I suggest that implementors of specifications which have a dependency 
on RFC 2616 review the relevant section in 
draft-ietf-httpbis-p1-messaging-24 about line folding and comment if 
they consider the deprecation as a problem.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Tue, 29 Oct 2013 06:39:14 -0700

Hi Julian,
At 08:53 28-10-2013, Julian Reschke wrote:
>My understanding is that we wanted to set a high bar because this 
>really ought to happen with lots of care and review.
>
>The related ticket is 

I'll consider this as addressed.

Regards,
S. Moonesamy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Oct 2013 17:03:30 +0100

On 2013-10-27 19:44, S Moonesamy wrote:
> 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.
> ...

I have trouble parsing this comment. Do you see an issue here?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 14:53:36 +0100

On 2013-10-28 17:55, S Moonesamy wrote:
> There is an IETF specification which interpreted Section 4.2 of RFC 2616
> as follows:
>

<http://tools.ietf.org/html/rfc4918#section-10.4.2>

So yes, this is a change from 2616 that we made due to security problems 
(header injection).

> Section 4.2 of RFC 2616 (and RFC 2068) follows the same generic format
> as that given in Section 3.1 of RFC 822.  Section 2.2 of RFC 2616 states
> that:
>
> I suggest that implementors of specifications which have a dependency on
> RFC 2616 review the relevant section in

Review is always good.

Note that the change is listed in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-24.html#rfc.section.A.2.p.8>:

"Header fields that span multiple lines ("line folding") are deprecated. 
(Section 3.2.4)"

Best regards, Julian