Subject: Magnus Westerlund's Discuss on draft-ietf-httpbis-header-structure-18: (with DISCUSS and COMMENT)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Wed, 20 May 2020 09:14:16 -0700

Magnus Westerlund has entered the following ballot position for
draft-ietf-httpbis-header-structure-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

A. Section 3.1:

   The ABNF for Lists in HTTP fields is:

   sh-list       = list-member *( *SP "," *SP list-member )
   list-member   = sh-item / inner-list

   Each member is separated by a comma and optional whitespace.

To me there is a clarity issue that could lead to interoperability issues.
Namely the difference in the meaning of whitespace between RFC 7230 and this
document. Structured headers appear to not allow the HTAB that RFC7230 allows.
And that is fine, but I would expect this to be more clearly discussed. If the
intention was to allow for HTAB you need to use WSP rather than SP in above
rule.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. Section 2, page 8:
   --8<--
     42. Foo-Example Header

   The Foo-Example HTTP header field conveys information about how
   much Foo the message has.

   Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be
   an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is:

     Foo-Example = sh-integer

   Its value indicates the amount of Foo in the message, and MUST
   be between 0 and 10, inclusive; other values MUST cause
   the entire header field to be ignored.

   The following parameters are defined:
   * A Parameter whose name is "foourl", and whose value is a String
     (Section Y.Y of [RFCxxxx]), conveying the Foo URL
     for the message. See below for processing requirements.

   "foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If
   its value is not a valid URI-reference, the entire header field
   MUST be ignored. If its value is a relative reference (Section 4.2
   of [RFC3986]), it MUST be resolved (Section 5 of [RFC3986]) before
   being used.

   For example:

     Foo-Example: 2; foourl="https://foo.example.com/"
   --8<--

To me this example indicates several unclarities in this specification.

First there is a lack of discussion of the definition of the field-name and
clearly identify it. In the above example it is only implicit identified. I
would propose that this example has an additional paragraph that explicitly
defined the Structure header name as discussed in the paragraph above this
example.

Per RFC 7230 Section 3.2 a header field is the complete structure of field-name
":" OWS field-value OWS. However looking at this example it appears that
structured header field only define the field-value. Wouldn't it be better to
be explicit about these two components although I understand that field-name is
a constant. This is also evident in what appears to be a grammatical error in
the above paragraph:

   Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be
   an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is:

The second "Its" would to me indicate Foo-Example a Item Structured Header, not
the header value (field-value in ABNF) which is defined. I would suggest
changing the second Its to "The Structured header value ABNF is:"

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 May 2020 13:29:41 +1000

Hi Magnus,

Thanks for the review. Responses below.

> On 21 May 2020, at 2:14 am, Magnus Westerlund via Datatracker <[email-masked]> wrote:

Hm. Conceivably, someone (e.g., an intermediary or a library) could combine two header instances and use COMMA HTAB; while the current text in 7230 only says "separated by a comma", but the (I believe more correct) text in semantics-core says "separated by a comma and optional whitespace. For consistency, use comma SP."

I think the chances of that actually being a problem are very, very small; by far the most common practice is comma SP. However, it's hard to rule out completely.

At this late stage, this is a non-trivial change; the risk of an implementation not updating for it is relatively low, but the risk of getting the fix wrong is much higher. So, I'm going to prepare a pull request and circulate it in the community to both get more eyes on it, and make sure the change gets consensus.

This is how we define HTTP headers; see for example the core documents, RFC7230, or most any of the extensions we're working on. There's been a lot of discussion leading up to this, and I won't reiterate all of that here; but it's pretty settled.

> changing the second Its to "The Structured header value ABNF is:"

I don't think that's an improvement.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 May 2020 15:41:20 +1000

> On 21 May 2020, at 1:29 pm, Mark Nottingham <[email-masked]> wrote:
> 

See:
  https://github.com/httpwg/http-extensions/pull/1173  <- spec changes
  https://github.com/httpwg/structured-header-tests/pull/43  <- test changes

Cheers,

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 May 2020 08:42:31 +0000

Hi Mark,

To be clear do what ever the you think are best. From my perspective restricting
this to space is a more strict and gets things done. However, calling space only
white space would be inconsistent which is why I raised this. 

Establish consensus and when it is done and a new version is availble I am happy
to clear my discuss. 

Regarding my comment. I do understand that there are praxis here. And it is
surprising how some of that praxis has been diverging between the protocols
being based on the same original specification practice.

Cheers

Magnus Westerlund

On Thu, 2020-05-21 at 15:41 +1000, Mark Nottingham wrote:
> > At this late stage, this is a non-trivial change; the risk of an
> > implementation not updating for it is relatively low, but the risk of
> > getting the fix wrong is much higher. So, I'm going to prepare a pull
> > request and circulate it in the community to both get more eyes on it, and
> > make sure the change gets consensus.
> 
> See:
>   
> https://protect2.fireeye.com/v1/url?k=c29eca4c-9c3e0809-c29e8ad7-86b568293eb5-76b0bb19f9189163&q=1&e=0a591911-0f72-4200-8724-64820ea5520e&u=https%3A%2F%2Fgithub.com%2Fhttpwg%2Fhttp-extensions%2Fpull%2F1173
> 73  <- spec changes
>   
> https://protect2.fireeye.com/v1/url?k=511d7dde-0fbdbf9b-511d3d45-86b568293eb5-f07a3cd74de055a4&q=1&e=0a591911-0f72-4200-8724-64820ea5520e&u=https%3A%2F%2Fgithub.com%2Fhttpwg%2Fstructured-header-tests%2Fpull%2F43
> 43  <- test changes
> 
> Cheers,
> 
> --
> Mark Nottingham   
> https://protect2.fireeye.com/v1/url?k=664dfdc0-38ed3f85-664dbd5b-86b568293eb5-696163c8015aa2e3&q=1&e=0a591911-0f72-4200-8724-64820ea5520e&u=https%3A%2F%2Fwww.mnot.net%2F
> 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 May 2020 11:01:12 +0200

On 21.05.2020 10:42, Magnus Westerlund wrote:
> ...

FWIW, Mark is right that we need to deal with HTAB on the wire, because
the HTTP spec allows it to be inserted.

The alternative solution would be to normalize HTAB before parsing, but
that would be tricky as we really want to allow it between list elements.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 21 May 2020 08:58:54 +0000

--------
In message <[email-masked]>, Magnus Westerlund writ

>white space would be inconsistent which is why I raised this.

One (thin) argument for OWS:  More legacy headers can probably be parsed with a SF parser.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.