- From: Vasiliy Faronov <vfaronov@gmail.com>
- Date: Fri, 24 Feb 2017 05:16:09 +0300
- To: Kazuho Oku <kazuhooku@gmail.com>, ietf-http-wg@w3.org
Kazuho, thank you for clarifying. On Fri, Feb 24, 2017 at 4:34 AM, Kazuho Oku <kazuhooku@gmail.com> wrote: > I think that the client should discard it, because (contrary to the > expectation) the server did not include the Warning header in the > final response, and because the draft states that: > > However, the evaluation MUST NOT affect > how the final response is processed; the client must behave as if it > had not seen the informational response. This makes 103 a special case in HTTP processing, sort of like HEAD or 204. A client that understands 1xx, but doesn't know 103 specifically, would handle such a header differently. If, instead, you defined headers on a 103 response as applying *both* to the 103 response *and* to the final response (speculatively), then there would be no such special-casing, while rel=preload would work the same. (Content-* might still need special-casing for 103, but they are already defined in terms of "associated representation" for the special case of HEAD.) Of course, this won't be a problem in practice if 103 is only used for rel=preload. This isn't causing me any trouble, just something I wanted to point out for your consideration. -- Vasiliy
Received on Friday, 24 February 2017 02:24:36 UTC