search

tatsuhiro-t / spdylay

The experimental SPDY protocol version 2, 3 and 3.1 implementation in C
http://tatsuhiro-t.github.io/spdylay/
MIT License
603 stars 102 forks source link

Client streams are not resetable #14

Closed sorced-jim closed 12 years ago

sorced-jim commented 12 years ago

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 commented 12 years ago

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: https://github.com/tatsuhiro-t/spdylay/issues/14

sorced-jim commented 12 years ago

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

tatsuhiro-t commented 12 years ago

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