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

Client streams are not resetable #14

Closed
sorced-jim opened this issue Mar 2, 2012 · 3 comments
Closed

Client streams are not resetable #14

sorced-jim opened this issue Mar 2, 2012 · 3 comments

Comments

@sorced-jim
Copy link

It is not possible to reset in progress streams from the client at the moment. The reason is that a client calls
spdylay_submit_request with some stream user data. The users callbacks get the stream user data to pass information to the client. However, the stream id is needed to call spdylay_submit_rst_stream.

I'm currently hacking around this by setting the stream id on my stream user data object in my request body callback and the syn_reply callback.

This means that for bodiless requests can't be cancelled between sending a request and getting the first control header for the response.

I think the solution would be to return the stream_id from submit_request.

@tatsuhiro-t
Copy link
Owner

2012年3月3日6:47 sorced-jim
reply@reply.github.com:

It is not possible to reset in progress streams from the client at the moment. The reason is that a client calls
spdylay_submit_request with some stream user data. The users callbacks get the stream user data to pass information to the client. However, the stream id is needed to call spdylay_submit_rst_stream.

I'm currently hacking around this by setting the stream id on my stream user data object in my request body callback and the syn_reply callback.

I think you can use before_ctrl_send_callback here.
In SYN_STREAM, this callback is called after stream is opened and its
frame->syn_stream.stream_id
has valid stream ID assigned. The
spdylay_session_get_stream_user_data() can be called from there.

This means that for bodiless requests can't be cancelled between sending a request and getting the first control header for the response.

I think the solution would be to return the stream_id from submit_request.

I use heap to sort pending SYN_STREAM frames in priority so that
higher one gets sent early.
This means we could not determine the stream ID before SYN_STREAM is
about to sent because
the frame with higher priority added later will have smaller stream ID
than the frame with lower priority
added before.


Reply to this email directly or view it on GitHub:
#14

@sorced-jim
Copy link
Author

I'll leave this bug open until there is some documentation about this.

@tatsuhiro-t
Copy link
Owner

I documented about this in spdylay.h. I also added simplified time chart which tells when callback functions are called.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants