Great – looks like our stack handles it properly, but our developer tools don’t. (Shows 103 and the Link: header as the response from the server; the 200 and its headers are nowhere to be found.) I’ve filed a bug.
From: Tatsuhiro Tsujikawa [mailto:tatsuhiro.t@gmail.com]
Sent: Thursday, November 3, 2016 8:32 AM
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Cory Benfield <cory@lukasa.co.uk>; Mike Bishop <Michael.Bishop@microsoft.com>; Julian Reschke <julian.reschke@gmx.de>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt
Hi,
On Wed, Nov 2, 2016 at 11:40 AM, Kazuho Oku <kazuhooku@gmail.com<mailto:kazuhooku@gmail.com>> wrote:
2016-11-02 7:08 GMT+09:00 Cory Benfield <cory@lukasa.co.uk<mailto:cory@lukasa.co.uk>>:
>
>> On 1 Nov 2016, at 17:24, Mike Bishop <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>> wrote:
>>
>> 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.
>
> Were you interested in a HTTP/1.1 or HTTP/2 endpoint? I can put one up that unconditionally returns a 103, though it may just be easier to spin up H2O or nghttp2.
I would very much appreciate it if you or somebody else could setup a
server that returns 103 so that people could check.
I won't have time for doing that myself for a week or so, and at the
moment H2O is incapable for sending 103 (it only recognizes 103 sent
from upstream and converts it into H2 push).
Meanwhile, I took my liberty, and setup h1 and h2 endpoint for 103 with link rel=preload.
Access https://nghttp2.org/?103-eh and you will get 103, and then 200 final status code.
There is no negotiation at the moment.
Best regards,
Tatsuhiro Tsujikawa