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.

Sign up for GitHub

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

Jump to bottom

Define initial PRIORITY frame and remove exclusive dependencies #2075

Merged
merged 7 commits into from Dec 6, 2018
Merged

Define initial PRIORITY frame and remove exclusive dependencies #2075

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
4fb06f0
INITIAL_PRIORITY
MikeBishop Nov 29, 2018
9ec6b29
Re-merge INITIAL_PRIORITY and PRIORITY, per Kazuho and Lucas
MikeBishop Dec 3, 2018
1b22092
Rework error layout
MikeBishop Dec 3, 2018
1920b13
More error shuffling
MikeBishop Dec 3, 2018
0141a42
Merge remote-tracking branch 'origin/master' into http/not_excusive
MikeBishop Dec 5, 2018
9acfcf6
Limit references to existing elements
MikeBishop Dec 5, 2018
c66e724
Explicitly prohibit invalid PET values
MikeBishop Dec 6, 2018
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
18 changes: 10 additions & 8 deletions draft-ietf-quic-http.md
View file
Open in desktop
Expand Up @@ -472,10 +472,11 @@ The PRIORITY (type=0x02) frame specifies the client-advised priority of a
stream.

When opening a new request stream, a PRIORITY frame MAY be sent as the first
frame of the stream. In order to ensure that prioritization is processed in a
consistent order, any subsequent PRIORITY frames MUST be sent on the control
stream. A PRIORITY frame received after other frames on a request stream MUST
be treated as a stream error of type HTTP_UNEXPECTED_FRAME.
frame of the stream creating a dependency on an existing element. In order to
ensure that prioritization is processed in a consistent order, any subsequent
PRIORITY frames MUST be sent on the control stream. A PRIORITY frame received
after other frames on a request stream MUST be treated as a stream error of type
HTTP_UNEXPECTED_FRAME.

Subsequent PRIORITY frames sent on the control stream might arrive before
PRIORITY frames sent on a request stream due to reordering. PRIORITY frames on
Expand Down Expand Up @@ -552,10 +553,11 @@ the interpretation of the associated Element ID fields.
Note that the root of the tree cannot be referenced using a Stream ID of 0, as
in {{!RFC7540}}; QUIC stream 0 carries a valid HTTP request. The root of the
tree cannot be reprioritized. A PRIORITY frame sent on a request stream that
prioritizes any other stream MUST be treated as a stream error of type
HTTP_MALFORMED_FRAME. Likewise, a PRIORITY frame sent on a control stream that
prioritizes the current stream MUST be treated as a connection error of type
HTTP_MALFORMED_FRAME.
prioritizes any other stream or expresses a dependency on a request with a
Copy link
Member

Choose a reason for hiding this comment

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

I am not sure if we need "prioritizes any other stream or".

Now that exclusive flag is going away, is there any case that could hit this condition?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is a perhaps-unclear reference to a PRIORITY frame where Prioritized Element Type is not 11 (i.e. the thing being prioritized is anything other than "this stream").

Copy link
Member

Choose a reason for hiding this comment

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

Ah. Thank you for the clarification. I missed that.

My preference goes to stating that Prioritized Element Type MUST be 11 when the frame is sent on a request stream and that it MUST NOT be 11 when the frame is sent on a control stream.

This is because I prefer to avoid having multiple representation that means the same; under the current provision, it seems that PEID could be encoded in two ways for a PRIORITY frame sent on a request stream; either set Prioritized Element Type to 11 or set it to 00 and set Prioritized Element ID to the ID of the stream. I fear that we might see interoperability issues in the wild if most of the clients use the 11 form but some used the 00 form.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point. The requirement for the values was already there (in the definition of Prioritized Element Type), but I'll scope the required-error language to the specific values as well.

greater Stream ID than the current stream MUST be treated as a stream error of
type HTTP_MALFORMED_FRAME. Likewise, a PRIORITY frame sent on a control stream
that prioritizes the current stream MUST be treated as a connection error of
type HTTP_MALFORMED_FRAME.
Copy link
Member

Choose a reason for hiding this comment

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

I am not sure what the intent of the last sentence is.

My understanding is that a PRIORITY frame can only refer to a "Stream ID of a request stream" (assuming that the type bits are 00 (i.e. Request stream). Therefore, I think that we do not need this sentence.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the inverse of the above -- sending 11 on a control stream, indicating that the thing being prioritized is the control stream itself.


When a PRIORITY frame claims to reference a request, the associated ID MUST
identify a client-initiated bidirectional stream. A server MUST treat receipt
Expand Down