- From: Shigeki Ohtsu <ohtsu@iij.ad.jp>
- Date: Thu, 06 Nov 2014 16:08:46 +0900
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
One more thing we should consider when an idle stream is in the priority tree is that in 5.1.1 Stream Identifiers says The first use of a new stream identifier implicitly closes all streams in the "idle" state that might have been initiated by that peer with a lower-valued stream identifier. If this description is not changed, we should also change all idel streams in the priority tree into the closed state which has a timeout value when the stream of larger id is closed. Regards, On 2014/11/06 15:29, Shigeki Ohtsu wrote: > > On 2014/11/06 14:29, Martin Thomson wrote: >> On 5 November 2014 18:48, Shigeki Ohtsu <ohtsu@iij.ad.jp> wrote: >>> Can't we use just HEADERS with a priority flag and no header block as a >>> group anchor >>> instead of using PRIORITY for an idle stream? >> I'm concerned that will result in problems for servers. There will >> always be a header block, but it will just be empty. If there are >> missing header fields, then the server will reject the "request". > > Empty header block in HEADES with END_HEADER flags is not explicitly > prohibited > in the current draft and permitted in the past when we have the > reference set. > > I agree that there may be a server that checks empty header set > emission and > rejects such a request. > >>> This might work since the reference sets has gone and a stream >>> timeout is >>> not defined yet in the current spec. >>> >>> I'm worrying about the idle stream in the priority tree is out of >>> SETTINGS_MAX_CONCURRENT_STREAMS. >> There is already a need to maintain priority information that is >> independent of the concurrent stream limit and to have nodes in the >> tree that are not active. See >> http://http2.github.io/http2-spec/#priority-gc This just makes that a >> little bit more flexible. > > This depends on the implementation design. > > For me, maintaining closed streams in the tree is much easier as we > can handle it > at the time when the stream state is transited (half-closed->closed, > reserved->closed). > > PRIORITY for an idle stream leads no stream state transition and they > can be increased > with no limits and they are preserved in the tree until we trigger gc > so I think this causes > more complex than the case of HEADERS with priority and no header block. > > Regards, > >
Received on Thursday, 6 November 2014 07:09:15 UTC