Editorial Issues: Section 4.2.2

Current:

  ":method":  the HTTP method for this request (e.g.
  "GET", "POST", "HEAD", etc) ([HTTP-p2], Section 4)

  ":path":  ":path" - the request-target for this URI with "/"
  prefixed (see [HTTP-p1], Section 3.1.1).  For example, for
  "http://www.google.com/search?q=dogs" the path would be
  "/search?q=dogs". [[anchor26: what forms of the HTTPbis
  request-target are allowed here?]]

  These header fields MUST be present in HTTP requests.

  In addition, the following two name-value pairs MUST be present in
  every request:

  ":host":  the host and optional port portions (see [RFC3986],
  Section 3.2) of the URI for this request (e.g. "www.google.com:
  1234").  This header field is the same as the HTTP 'Host'
  header field ([HTTP-p1], Section 5.4).

  ":scheme":  the scheme portion of the URI for this request (e.g.
  "https")

Note the double ":path": ":path" : in the second paragraph.

Also, why are these split into two sections? "These... MUST be
present... In addition, the following two... MUST be present..." ..
Recommend reworking this to:

  The following fields MUST be present in all HTTP requests:

  ":method":  the HTTP method for this request (e.g.  "GET", "POST",
  "HEAD", etc) ([HTTP-p2], Section 4)

  ":path":  the request-target for this URI with "/"
  prefixed (see [HTTP-p1], Section 3.1.1).  For example, for
  "http://www.google.com/search?q=dogs" the path would be
  "/search?q=dogs". [[anchor26: what forms of the HTTPbis
  request-target are allowed here?]]

  ":host":  the host and optional port portions (see [RFC3986],
  Section 3.2) of the URI for this request (e.g. "www.google.com:
  1234").  This header field is the same as the HTTP 'Host'
  header field ([HTTP-p1], Section 5.4).

  ":scheme":  the scheme portion of the URI for this request (e.g.
  "https")

Also, I recommend removing the additional requirement given in the
paragraph that follows:

  All header field names starting with ":" (whether defined in this
  document or future extensions to this document) MUST appear before
  any other header fields.

The challenge with this is that if we go with any of the proposed
Delta-based header encoding schemes currently on the table, it is
difficult to ensure that : prefixed headers are encoded first in the
header block. It may even be counter productive to the task of
producing an optimized serialization.

- James

Received on Wednesday, 24 April 2013 17:12:25 UTC