Re: Editorial Issues: Section 4.2.2

Hey James,


On 24 April 2013 10:11, James M Snell <jasnell@gmail.com> wrote:
> 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")

Feel free to send a pull request for this.  I see no reason not to
make this sort of change.

There are a lot of less obvious edits of this nature.  From my
perspective, there are too many to fix at once.  For instance, the
entirety of Section 5 needs to be moved to more relevant locations.

There's no reason why you can't just raise an issue or pull request
for editorial stuff that bugs you.

> 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.

I'm going to suggest that we defer this and remove it when we edit in
header compression, if necessary.  There may be a way to retain this
property.  For instance, we might require operations on ':'-headers to
occur before non-':'-headers.  That might not surface in some
implementations (I wouldn't see why this is something that you would
preserve in your Java implementation, it's just unnecessary
complication), but it might make a routing intermediary marginally
more performant.

--Martin

Received on Wednesday, 24 April 2013 18:14:03 UTC