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
Move QPACK control instructions to dedicated streams #1238
Conversation
Rather than hard-code, I would greatly prefer that this used a stream header. |
Can you explain the basis of your preference? A client has no other unidirectional streams defined in HTTP over QUIC, and a server must process/acknowledge at least one header block before opening any push streams. It is further very unlikely the server would open a push stream without first encoding a header block that inserts at least one header to the dynamic table. So in practice it's going to work out to these streams anyways. How do you see the encode/decode streams as materially different from the control stream, which is hardcoded? Aside: it occurs to me that a server could compress a PUSH_PROMISE a lot better if it compressed against the client's table, which of course doesn't work ;) |
Looks reasonable. The source of the stream header is, I think, the discussion in #910 about eliminating references to particular stream IDs in the application layer. You can make a QUIC interface that depends only on receiving a stream and reading the bytes to figure out what to do with it, rather than needing to open / listen on particular streams by ID. I think that model is important for things that could crop up mid-connection, but I don't feel as strongly about the header for streams that are unique and persistent. |
c3e6633
to
456a343
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rebased onto the changes in master, but kept the changes from the original PR.
draft-ietf-quic-qpack.md
Outdated
|
||
Table updates can add a table entry, possibly using existing entries to avoid | ||
transmitting redundant information. The name can be transmitted as a reference | ||
to an existing entry in the static or the dynamic table or as a string literal. | ||
For entries which already exist in the dynamic table, the full entry can also be | ||
used by reference, creating a duplicate entry. | ||
|
||
Each set of encoder insructions is prefaced by its length, encoded as a variable | ||
length integer with an 8-bit prefix. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably specify that these need to be complete instructions (i.e. no truncation), and require an error if one of the length-prefixed blocks ends mid-instruction.
a01b60c
to
6175998
Compare
6175998
to
e8d22aa
Compare
Fixes #1121
Fixes #1122