- From: Shigeki Ohtsu <ohtsu@iij.ad.jp>
- Date: Wed, 17 Jul 2013 21:39:43 +0900
- To: HTTP Working Group <ietf-http-wg@w3.org>
Hi, The stream state is newly introduced in the draft-04. For my understandings, I've just wrote a table diagram for the stream states transition to cover all scenarios in the case of sending and receiving frames. The table is listed in http://html5.ohtsu.org/HTTP2_Stream_State.pdf In writing this, I have the folowing five questions which are painted gray in the table field. (1) Receiving RST_STREAM in "idle" Is it a stream error with PROTOCOL_ERROR or falled into "closed" state? (2) Receivng PRIRORITY and WINDOW_UPDATE in "half closed(local)" They are not necessary. So is it to be an error or ignored? (3) Sending PRIORITY in "half closed(remote)" No description about this case is in the draft. Is it prohibited? (4) Receiving RST_STREAM in "closed" The draft says that " An endpoint that sends a RST_STREAM frame MUST ignore frames that it receives on closed streams after it has sent a RST_STREAM frame." Is this ignored always in the closed state or only in the case after RST_STREAM sent? (5) Receiving PUSH_PROMISE in "closed" The draft says that 'An endpoint might receive a PUSH_PROMISE frame after it sends RST_STREAM. PUSH_PROMISE causes a stream to become "reserved".' The same question above. Is PUSH_PROMISE always leads the associted stream to be reserved(remote) in the closed state? Or is it limited in the case after RST_STREAM was sent? If any missings or mistakes are found in the table, I'm very glad to have feedbacks. Regards,
Received on Wednesday, 17 July 2013 12:40:16 UTC