- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Wed, 23 Nov 2016 19:07:17 +0100
- To: McManus Patrick <mcmanus@ducksong.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
> Am 23.11.2016 um 10:15 schrieb Stefan Eissing <stefan.eissing@greenbytes.de>: > > Thanks Patrick, > >> Am 22.11.2016 um 23:26 schrieb Patrick McManus <mcmanus@ducksong.com>: >> >> Dear Gentlefolk of HTTPbis, >> >> This is a followup to Kazuho's presentation in Seoul[*] where he discussed https://datatracker.ietf.org/doc/draft-kazuho-early-hints-status-code/ >> >> The idea seemed to have acceptance (both in the room and on the list) with some concerns expressed about interoperability. Kazuho was kind enough to publish an endpoint so you can test if the client you implement has an unexpected failure in the face of 103. >> >> However, the draft was published pretty close to meeting time and there wasn't much space for discussion in the room. So before we do a Call For Adoption, I would like to hear some more discussion so the chairs can be confident there is interest - even if that discussion is "I would like to implement that" or "what does that accomplish?". Please do chime in, your silence will be taken for disinterest otherwise :). > > I have released support for 103 in mod_http2 in the standalone github v1.8.0 and plan to include same code in the next Apache httpd release (mod_http2 being an experimental part makes that easy). 103 is, so far, only used over HTTP/2 connections there. I am waiting for some consensus to arrive on how to make best use of it over HTTP/1.1 (other than proprietary tweaks in reverse proxy/backend setups), if at all. > > 103 allows signalling of PUSH options by the backend way earlier than before (in connection time) and its implementation is very straightforward. > > -Stefan Not to be mistaken, 103 on HTTP/2 connections will be disabled by default, as some html-rendering clients report ERR_SPDY_PROTOCOL_ERROR... :-S
Received on Wednesday, 23 November 2016 18:07:52 UTC