Last-call feedback for "Structured Headers for HTTP"

[wenbozhu]

https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-15

Nits

• "individual individual" (4.2.)

Clarification

• re: "lists can have their members split across multiple instances inside a block of fields", it will be useful to add a reference on the strict order of HTTP headers (of the same key)
• max # of items for innerlist: why not 1024 too? It seems a bit arbitrary to go with a smaller number
• 3.3.5 could you mention the max length of the encoded header value, in addition?

Suggestions

• can utf-8 be the only encoding option?
• can you add an appendix on any existing headers that already comply with this spec, or examples of some complicated headers that could have benefited from structured headers? This might encourage the implementations of "structured headers"
• it will be useful to mention how the authors expect this spec to be extended in future (or not), e.g. new item types, nested inner-lists

---

Great work! Look forward to implementing this soon.

[mnot]

Thanks for the review!

"individual individual" (4.2.)

Fixed.

re: "lists can have their members split across multiple instances inside a block of fields", it will be useful to add a reference on the strict order of HTTP headers (of the same key)

Fixed.

max # of items for innerlist: why not 1024 too? It seems a bit arbitrary to go with a smaller number

1024 * 1024 is a lot, especially considering the limits that most implementations will put on total header size

3.3.5 could you mention the max length of the encoded header value, in addition?

We're trying to just limit the abstract types, so that it's consistent between different serialisations.

can utf-8 be the only encoding option?

The reference to UTF-8 is only advice; people can put whatever arbitrary binary data they want into the binary type.

can you add an appendix on any existing headers that already comply with this spec, or examples of some complicated headers that could have benefited from structured headers? This might encourage the implementations of "structured headers"

That's out of scope for this work, but see draft-nottingham-binary-structured-headers

it will be useful to mention how the authors expect this spec to be extended in future (or not), e.g. new item types, nested inner-lists

I think we can defer that, because new extensions will have to update this specification (going through the appropriate process); it's not intended to have modular extensibility.