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

Clarify HTTP/2 setting parameter reservation #3955

Merged
merged 5 commits into from Sep 1, 2020
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
14 changes: 8 additions & 6 deletions draft-ietf-quic-http.md
Expand Up @@ -1398,7 +1398,8 @@ value the implementation selects.

Setting identifiers which were used in HTTP/2 where there is no corresponding
HTTP/3 setting have also been reserved ({{iana-settings}}). These settings MUST
NOT be sent, and receipt MAY be treated as an error of type H3_SETTINGS_ERROR.
NOT be sent, and their receipt MUST be treated as an error of type
H3_SETTINGS_ERROR.

Additional settings can be defined by extensions to HTTP/3; see {{extensions}}
for more details.
Expand Down Expand Up @@ -2311,16 +2312,18 @@ frame of the control stream, and thereafter cannot change. This eliminates many
corner cases around synchronization of changes.

Some transport-level options that HTTP/2 specifies via the SETTINGS frame are
superseded by QUIC transport parameters in HTTP/3. The HTTP-level options that
are retained in HTTP/3 have the same value as in HTTP/2.
superseded by QUIC transport parameters in HTTP/3. The HTTP-level options that
are retained in HTTP/3 have the same value as in HTTP/2. The superseded
settings are reserved, and their receipt is an error. See
{{settings-parameters}} for discussion of both the retained and reserved values.

Below is a listing of how each HTTP/2 SETTINGS parameter is mapped:

SETTINGS_HEADER_TABLE_SIZE:
: See [QPACK].

SETTINGS_ENABLE_PUSH:
: This is removed in favor of the MAX_PUSH_ID which provides a more granular
: This is removed in favor of the MAX_PUSH_ID, which provides a more granular
control over server push. Specifying a setting with the identifier 0x2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we instead phrase these as normative? For example: Endpoints MUST NOT send a setting with identifier 0x2 (corresponding to the SETTINGS_ENABLE_PUSH parameter) in the HTTP/3 SETTINGS frame.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing in this appendix is normative, by design. The normative requirement is in the body of the document, and this appendix simply notes that there is a prohibition. I could add a reference to the prohibition, if that would help.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A reference to the prohibition works for me, I just want to make sure we have easily-discoverable text clearly stating that endpoints MUST NOT send those

(corresponding to the SETTINGS_ENABLE_PUSH parameter) in the HTTP/3 SETTINGS
frame is an error.
Expand All @@ -2343,8 +2346,7 @@ SETTINGS_MAX_FRAME_SIZE:
HTTP/3 SETTINGS frame is an error.

SETTINGS_MAX_HEADER_LIST_SIZE:
: This setting identifier has been renamed SETTINGS_MAX_FIELD_SECTION_SIZE. See
{{settings-parameters}}.
: This setting identifier has been renamed SETTINGS_MAX_FIELD_SECTION_SIZE.

In HTTP/3, setting values are variable-length integers (6, 14, 30, or 62 bits
long) rather than fixed-length 32-bit fields as in HTTP/2. This will often
Expand Down