Subject: Editorial Issues: Section 4.2.2

From: James M Snell <[email-masked]>
Date: Wed, 24 Apr 2013 10:11:37 -0700

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Apr 2013 11:13:31 -0700

Hey James,

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

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.

> 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

---

From: James M Snell <[email-masked]>
Date: Wed, 24 Apr 2013 11:19:39 -0700

> for editorial stuff that bugs you.

I can submit pull requests. Is there a specific process the editors
would like re: pull requests? For instance, posting a note here on
list when a pull request is submitted so that everyone can be aware of
the suggested change?

- James

---

From: James M Snell <[email-masked]>
Date: Wed, 24 Apr 2013 12:06:43 -0700

This is now: https://github.com/http2/http2-spec/issues/70

[snip]

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Apr 2013 16:45:31 -0700

If you believe that the issue is purely editorial - a wording change,
moving stuff into more logical places, etc... - then just open the
pull request.  Poke an editor if you see it neglected.

If you aren't sure, come to the list.  You might get a "yeah, that's
just editorial" response, but it gives people a chance to discuss it.

Key goals are: a) conduct technical discussions on the list, and b)
conduct technical discussions on the list.  Too much editorial (and
procedural) stuff drives down the signal to noise ratio.  Too little
and you risk having edits go in without working group input.