-
Notifications
You must be signed in to change notification settings - Fork 16
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
Per-hop behaviour of Subscribe requests #62
Comments
Wow, I am so grateful to hear this! I had not thought about that. Thank you for coming and applying your mind to this problem! We don't have anyone else experienced with proxies in the group, yet, and I can see that you've got a lot you can contribute. So yes, I think you're right. I wasn't even aware of the Connection header or SETTING spec. I will do some research. Thank you! |
And I'll have to admit, I'm not the most experienced HTTP/2 expert out there. We're going to need to think carefully about the implementation in H/2. All connection-related headers have been removed from the request and moved into settings and frames. This means that a connection-related thing affects all requests on the same connection. So if you wanted to make a "Subscribe" request for a large object (say, an ever-updating-SVG-animation) and specifically not subscribe to another large object (say, a live video file being updated via append), we'll need to think carefully about how we allow the client to express that preference. Or perhaps declare that out of scope and say the client can use multiple connections if they need to. |
Interesting. So on the one-hand, it seems that the But on the other hand, the |
What if we used a subscription frame in H/2+? We could define a new frame type (unaware implementations MUST ignore) and use that for subscription. Then, it would be completely separate from any actual requests. If you want an actual object you can request it. Your subscription frame would then contain the headers necessary for setting up the subscription. You can look at the PUSH_PROMISE frame for an example in the opposite direction. In H/1, we just have to add |
I don't believe the currently described subscription routine will work properly when an unaware proxy lies between the origin and the client. The client can send a request to the proxy, which will forward the Subscribe header unaware of its meaning. The origin will then keep the connection open to the proxy indefinitely, which the proxy is definitely not prepared for. Most likely, the proxy will time out the connection and the client will get an error.
I don't see a way to do the Subscribe header that isn't per-hop. As a per-hop header, it would need to be included in the Connection header for HTTP/1 and be handled as a new SETTING in HTTP/2 and /3.
The text was updated successfully, but these errors were encountered: