- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 7 Aug 2012 17:33:05 -0700
- To: "Adrien W. de Croy" <adrien@qbik.com>
- Cc: Mike Belshe <mike@belshe.com>, Mark Nottingham <mnot@mnot.net>, Roberto Peon <grmocg@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CABP7RbfCLNhEMpVFSVwnrJs8cyB+57TXnU9z0cskoGue_vCeAw@mail.gmail.com>
On Tue, Aug 7, 2012 at 4:26 PM, Adrien W. de Croy <adrien@qbik.com> wrote: > > ------ Original Message ------ > From: "James M Snell" <jasnell@gmail.com> > > What exactly is your worry? > > My general concern about it deals more with application handling of the > response than with anything else... it would be good to apply some rules... > for instance... > > 1. An updated :status header MUST ONLY be sent if the initial SYN_REPLY > :status header is a 1xx response code, > 2. No more than one 1xx response code can be sent per response, > > this contravenes 2616 which explicitly states that any number may be sent, > and must be handled appropriately. > > > 3. Once a non 1xx :status has been sent, it is a protocol error to send > any additional :status headers, > > this is a semantic change. We actually now use multiple 1xx for status > updates in the lab. I don't know if there are other uses, but there are > legitimate use-cases for it. > > If 2.0 can support some other OOB notification mechanism, then all well > and good. > > Aw man.. you had to go and ruin it with Reality... how annoying ;-) I suppose that, at least in theory, we could support multiple 1xx :status headers to be sent so long as the final non-1xx :status is still sent *before* any response DATA frames, but that does get kind of messy and tedious... we'd end up having to check every HEADERS frame for a possible :status header that overrides the previously received one... and that just gets silly. The one thing I would note, however, is that HEADERS frames can be sent anytime in the stream making it possible for other kinds of signaling beyond :status to occur. The only restriction being how such additional HEADERS frames affect the HTTP semantics. - James > Adrien > > 4. The non 1xx :status header MUST be sent before any DATA frames are > sent in the response. > > With that, an application can be assured that they'll have the final > actual status code before processing any of the response data. > > - James > > > On Tue, Aug 7, 2012 at 4:08 PM, Mike Belshe < <mike@belshe.com> > mike@belshe.com> wrote: > >> >> [snip] >> Making SPDY (or HTTP/2.) suport it, however, is relatively simple. >> James' proposal in this thread is getting close. I'm a little worried >> about demarcation of the two sets of headers, but the rest is >> straightforward. >> >> Mike >> >> >> >> >>> >>> Cheers, >>> >>> -- >>> Mark Nottingham >>> <http://www.mnot.net/>http://www.mnot.net/ >>> >>> >>> >>> >>> >>> >> >
Received on Wednesday, 8 August 2012 00:33:58 UTC