Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QPACK should explicitly state ordering requirements for headers within a block #1684

Closed
afrind opened this issue Aug 17, 2018 · 1 comment
Closed
Labels
-qpack editorial An issue that does not affect the design of the protocol; does not require consensus.

Comments

@afrind
Copy link
Contributor

afrind commented Aug 17, 2018

From Bence via the mailing list:

HPACK Section 1.3 defines a "Header List" as "an ordered collection of header fields...". QPACK uses the term "Header Set" instead and does not require it to be ordered. HPACK has a whole section, 2.1, on ordering, whereas QPACK does not spell out this guarantee. However, since frames on a given stream are guaranteed to be ordered by the underlying transport, my impression is that QPACK as specified already guarantees to preserve order of header fields within a header list. (Also in my experience things can break in colorful ways if you start reordering headers in your application.)

I propose to add language on the requirement to preserve order, and to use the expression "header list" instead of "header set" throughout. The clause "header list ... can contain duplicate header fields" should probably also be included.

@afrind afrind added editorial An issue that does not affect the design of the protocol; does not require consensus. -qpack labels Aug 17, 2018
@bencebeky
Copy link
Contributor

Created #1725. Also, I should have titled this issue "...ordering requirements for header fields within a header list".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-qpack editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
None yet
Development

No branches or pull requests

2 participants