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

A server can't send SETTINGS first #515

Closed
martinthomson opened this issue May 10, 2017 · 2 comments
Closed

A server can't send SETTINGS first #515

martinthomson opened this issue May 10, 2017 · 2 comments
Labels
-http design An issue that affects the design of the protocol; resolution requires consensus.

Comments

@martinthomson
Copy link
Member

Stream 1 is a client-initiated stream. That means that the server can't send its SETTINGS frame to the client until it reads the end of the client handshake and stream 1 is opened. That's annoying because the server could otherwise send frames to the client after it sends its ServerHello.

In addition to SETTINGS, the server might use this otherwise dead air to send things like ORIGIN frames or secondary certificates.

This would not be a problem if streams were unidirectional ;)
@martinthomson martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. -http labels May 10, 2017
@janaiyengar
Copy link
Contributor

Alternatively, Stream 2 is available.

@janaiyengar
Copy link
Contributor

If there are specific things that you'd want the server to be able to send, we could reserve stream 2 for it. But I suppose SETTINGS would need to be received before the client processes things on stream 1, right? In which case, ordering between stream 1 and 2 will become an issue... hm.

@martinthomson martinthomson mentioned this issue Jun 20, 2017
Closed
martinthomson added a commit that referenced this issue Oct 18, 2017
@martinthomson
Make HTTP use bidirectional and unidirectional stream
c4b421b 
The changes in #885 don't include HTTP, which leaves that draft somewhat
broken.  This corrects the omission.

There is an obvious optimization for HTTP, which is to not send the low two
bits of the Stream ID whenever it needs to identify a stream.  Right now, the
protocol only ever mentions client-initiated, bidirectional streams in frames,
so those two bits are wasted.  I'll save that change for later though.

I have chosen to take the control stream and use two unidirectional streams, which
addresses #515.

Closes #515, #240, #281.
@martinthomson martinthomson mentioned this issue Oct 18, 2017
Merged
MikeBishop pushed a commit that referenced this issue Nov 11, 2017
@martinthomson @MikeBishop
Make HTTP use bidirectional and unidirectional stream
e0ac3d0 
The changes in #885 don't include HTTP, which leaves that draft somewhat
broken.  This corrects the omission.

There is an obvious optimization for HTTP, which is to not send the low two
bits of the Stream ID whenever it needs to identify a stream.  Right now, the
protocol only ever mentions client-initiated, bidirectional streams in frames,
so those two bits are wasted.  I'll save that change for later though.

I have chosen to take the control stream and use two unidirectional streams, which
addresses #515.

Closes #515, #240, #281.
@MikeBishop MikeBishop mentioned this issue Nov 11, 2017
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-http design An issue that affects the design of the protocol; resolution requires consensus.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Unidirectional Streams quicwg/base-drafts
2 participants
@martinthomson @janaiyengar