Subject: I-D Action: draft-ietf-httpbis-header-structure-07.txt

From: [email-masked]
Date: Mon, 02 Jul 2018 00:19:12 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Hypertext Transfer Protocol WG of the IETF.

        Title           : Structured Headers for HTTP
        Authors         : Mark Nottingham
                          Poul-Henning Kamp
	Filename        : draft-ietf-httpbis-header-structure-07.txt
	Pages           : 27
	Date            : 2018-07-02

Abstract:
   This document describes a set of data types and algorithms associated
   with them that are intended to make it easier and safer to define and
   handle HTTP header fields.  It is intended for use by new
   specifications of HTTP header fields as well as revisions of existing
   header field specifications when doing so does not cause
   interoperability issues.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-header-structure/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-07
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-header-structure-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-header-structure-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Richard Gibson <[email-masked]>
Date: Mon, 2 Jul 2018 12:03:07 -0400

I don't remember if I mentioned this in a previous draft, but I have 
issues with discarding headers that fail parsing, as specified in 
section 4.2. This allows broken client implementations to persist 
indefinitely, and experience surprising but potentially undetected 
behavior from servers. Shouldn't failure to parse a structured header 
result in rejection of the entire request?

Other comments:

In Section 2, the "Foo-Example Header" example text is hard to 
distinguish from the normative document text. I think it should be 
indented and/or moved into its own subsection.

Section 3.5 defines sh-integer to include 1*19DIGIT. If allowing leading 
zeroes is intentional, then it should be made explicit (and probably 
also deserves a mention in Section 4.2.6 steps 8.1 and 9.2).

Section 4.1.1 (Serialising a Dictionary) appears to be missing a step 
for emitting commas between key-value pairs.

Section 4.1.3 (Serialising a Parameterised List) appears to be missing a 
step for emitting semicolons before identifier parameters.

Section 4.1.4 (Serialising an Item) appears to be missing a step that 
appends "value" (the result of applying a type-specific serialisation 
algorithm) to "output" (the string that is returned).

Section 3.1 claims that dictionaries allow no whitespace on either side 
of "=" that separate keys and values, but Section 4.2.1 (Parsing a 
Dictionary from Text) uses Parse Item from Text after consuming the "=", 
and Section 4.2.5 defines that to begin with discarding "any leading OWS 
from input_string", thereby allowing post-"=" whitespace in dictionary 
parsing. The gap should be reconciled.

Should Structured Headers take a position on negative zeroes? Section 
4.1.6 (Serialising a Float) emits a negative sign if "input is less than 
(but not equal to) 0", which I believe is ambiguous in the context of 
IEEE 754. And Section 4.2.6 (Parsing a Number from Text) accepts 
negative zeroes, but preserves the sign only for floats.

On 07/02/2018 03:19 AM, [email-masked] wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dhttpbis-2Dheader-2Dstructure_&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=eySPBx2CiM8BUQ7FFWJY_4aibes77hMFF8Vxe5zUsYE&s=n24N_wOqqViSHpMN6iygCajclNm_--cMEz35GVhS1lA&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dhttpbis-2Dheader-2Dstructure-2D07&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=eySPBx2CiM8BUQ7FFWJY_4aibes77hMFF8Vxe5zUsYE&s=6DPpxSk9wh99qUR23gRZSmbbN9jM3Q6yuAbvKkviEXw&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dhttpbis-2Dheader-2Dstructure-2D07&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=eySPBx2CiM8BUQ7FFWJY_4aibes77hMFF8Vxe5zUsYE&s=hILTlBQ2WM-yZrJRazB4zqdjhy7nLjdl-RUIcFDSV-I&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dhttpbis-2Dheader-2Dstructure-2D07&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=eySPBx2CiM8BUQ7FFWJY_4aibes77hMFF8Vxe5zUsYE&s=I8qcQasE5dpfbU8v6hnnZp-H1abXmUL5rTHbv-wTTWM&e=
>
>
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=eySPBx2CiM8BUQ7FFWJY_4aibes77hMFF8Vxe5zUsYE&s=QPeJzVTuwpegeX8EO0zZOWpxCTx-dRuZ3Lltvw6ufWw&e=
>
>

---

From: Kari Hurtta <[email-masked]>
Date: Mon, 2 Jul 2018 22:08:55 +0300 (EEST)

Structured Headers for HTTP
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-07

4.2.  Parsing HTTP/1 Header Fields into Structured Headers
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-07#section-4.2

|   If parsing fails - including when calling another algorithm - the
|   entire header field's value MUST be discarded.  This is intentionally
|   strict, to improve interoperability and safety, and specifications
|   referencing this document cannot loosen this requirement.
|
|   Note that this has the effect of discarding any header field with
|   non-ASCII characters in input_string.

But parsing algorith seems missing text:

	If non-ASCII characters seen, fail parsing.

All algrithm have text

	"Given an ASCII string input_string"

so they do not apply situation when there is non-ASCII characters.

4.2.  Parsing HTTP/1 Header Fields into Structured Headers
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-07#section-4.2

|   Given an ASCII string input_string that represents the chosen
|   header's field-value, and header_type, one of "dictionary", "list",
|   "param-list", or "item", return the parsed header value.
 
4.2.1.  Parsing a Dictionary from Text
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-07#section-4.2.1

|   Given an ASCII string input_string, return a mapping of (identifier,
|   item). input_string is modified to remove the parsed value.

4.2.2.  Parsing a List from Text
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-07#section-4.2.2

|   Given an ASCII string input_string, return a list of items.
|   input_string is modified to remove the parsed value.

4.2.3.  Parsing a Parameterised List from Text
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-07#section-4.2.3

|   Given an ASCII string input_string, return a list of parameterised
|   identifiers. input_string is modified to remove the parsed value.

4.2.4.  Parsing a Parameterised Identifier from Text
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-07#section-4.2.4

|   Given an ASCII string input_string, return a identifier with an
|   mapping of parameters. input_string is modified to remove the parsed
|   value.

4.2.5.  Parsing an Item from Text
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-07#section-4.2.5

|   Given an ASCII string input_string, return an item. input_string is
|   modified to remove the parsed value.

4.2.6.  Parsing a Number from Text
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-07#section-4.2.6

|   NOTE: This algorithm parses both Integers Section 3.5 and Floats
|   Section 3.6, and returns the corresponding structure.

  4.2.6 seems to have exception, because it does not limit itself to
  "Given an ASCII string input_string" (but referring
     4.2.  Parsing HTTP/1 Header Fields into Structured Headers
  limits itself to  "Given an ASCII string input_string" ).

4.2.7.  Parsing a String from Text
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-07#section-4.2.7

|   Given an ASCII string input_string, return an unquoted string.
|   input_string is modified to remove the parsed value.

4.2.8.  Parsing an Identifier from Text
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-07#section-4.2.8

|   Given an ASCII string input_string, return a identifier. input_string
|   is modified to remove the parsed value.

4.2.9.  Parsing Binary Content from Text
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-07#section-4.2.9

|   Given an ASCII string input_string, return binary content.
|   input_string is modified to remove the parsed value.

So there seems to missing top level algorithm, which is

    Given an string input_string, return parsed context.

    1. Check input_string character values.

       1. If all characters are on range %x00-%x7f,
          let output be the result of 
          Parsing HTTP/1 Header Fields into Structured Headers
          (Section 4.2)

       2. Otherwise, fail parsing.

/ Kari Hurtta

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Jul 2018 12:37:58 +1000

Hi Kari,

> On 3 Jul 2018, at 5:08 am, Kari Hurtta <[email-masked]> wrote:
> 

[...]

>       2. Otherwise, fail parsing.

Seems reasonable to me, thanks!

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