Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

[Stefan Eissing <[e-mail]>]

Thanks Kazuho for putting forward this draft.

Apache httpd will on next release properly process, and forward unannounced 1xx responses until a final response arrives (read: it currently does not, shame on me). I plan to add support for converting 103 headers into PUSHes, but am unable to promise that for the next release. It may or may not happen. Interestingly, I might use 103 responses just internally in httpd to let the HTTP/1 parts trigger a push before starting processing the complete response.

Any 'Accept-EH' headers for proxying h1 connections are configurable via the usual directives. So that part is easily handled.

I plan to forward any 103 responses to the client, regardless if 103 triggered PUSHes or not. I sensed agreement here that we ask h2 implementations to just cope with that. 

The question I have in regard to timing: is there any requirement on PUSH_PROMISES to arrive before a 103 or can that one come first. (There was some sensibility in regard to final responses, so prefetches could adapt in time).

-Stefan
 
> Am 01.11.2016 um 18:24 schrieb Mike Bishop <[e-mail]>:
> 
> FWIW, our implementation should already ignore this response and process the final status code correctly.  If you have a public endpoint that returns a hint, we can all do a quick field test.
> 
> -----Original Message-----
> From: Cory Benfield [mailto:[e-mail]] 
> Sent: Tuesday, November 1, 2016 1:17 AM
> To: Julian Reschke <[e-mail]>
> Cc: Kazuho Oku <[e-mail]>; HTTP Working Group <[e-mail]>
> Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt
> 
> 
>> On 1 Nov 2016, at 06:32, Julian Reschke <[e-mail]> wrote:
>> 
>> On 2016-11-01 02:32, Kazuho Oku wrote:
>>> Cory, Julian, thank you for looking into the I-D.
>>> 
>>> Thank you for looking into the existing implementations using Python.
>>> Your research makes it evident that some kind of negotiation is 
>>> mandatory if we are going to use 103 on the public Internet.
>> 
>> Having to negotiate it makes me sad.
> 
> I’m right there with you Julian. The 1XX response category gets to be another marker pointing us to the lesson the IETF has been learning for the past decade or so: extension points on a specification that no-one uses rust over time and become unusable.
> 
> In this case, I think the 1XX problem is more oversight than anything else. The problems in all these cases are tractable, and can be fairly easily fixed. It’s just that someone needs to spend that time.
> 
>>> For HTTP/2, my tendency leans toward using HTTP headers rather than 
>>> having its own way of negotiation, considering the fact that the 
>>> information transferred using Early Hints could be considered 
>>> end-to-end rather than hop-by-hop, and also that we can expect HPACK 
>>> to compress Accept-EH header efficiently.
>> 
>> For HTTP/2, I think we should push stronger to fix the code and not negotiate at all.
> 
> So for HTTP/2 the state of play is different. There are far fewer implementations, and those that exist are better and more actively developed. I’m happy to say for h2 that we don’t require negotiation of the extension.
> 
> Cory