- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 10 Jan 2014 10:05:12 -0800
- To: Shigeki Ohtsu <ohtsu@iij.ad.jp>
- Cc: Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Thanks for picking this up. I've made some edits that address this: https://github.com/http2/http2-spec/commit/3f6da66705bfacaf9f325d3b9265d09d4c44fd3e (If we keep this up, we'll have a pretty solidly bulletproof spec by the end of this.) As always pull requests or other forms of feedback appreciated. On 8 January 2014 18:33, Shigeki Ohtsu <ohtsu@iij.ad.jp> wrote: > >> hmm, surprising that it wouldn't be defined, but I haven't checked lately. >> a connection-error is reasonable, but if the value of ENABLE_PUSH is >> changing, you'll want to ensure that you've received the ACK for the >> appropriate setting before treating it as an error. > > > Yes, there is a racing condition to synchronize ENABLE_PUSH. > A client needs to choice accept or reset promised streams in that case. > > >> And I also found no description of the case when a server receive >> PUSH_PROMISE. >> It should be also treated as a connection error. Right? >> >> >> There is nothing wrong with a server receiving a PUSH_PROMISE since the >> lower-layer stuff is symmetrical, though it makes little sense at the >> HTTP layer, which should probably treat it as an error of some kind. > > > Yes, in framing layer PUSH_PROMISE is defined with the word of an endpoint > neither a server nor a client. > > The terms of a server and a client in the sepc are defined as the condition > in which TCP connection is initiated so there can be an another world where > a non-HTTP request is sent from a server to a client. > >
Received on Friday, 10 January 2014 18:05:40 UTC