- From: Shigeki Ohtsu <ohtsu@iij.ad.jp>
- Date: Thu, 09 Jan 2014 11:33:18 +0900
- To: Roberto Peon <grmocg@gmail.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
> 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 Thursday, 9 January 2014 02:33:46 UTC