Subject: Adam Roach's No Objection on draft-ietf-httpbis-early-hints-04: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 01 Aug 2017 16:19:09 -0700

Adam Roach has entered the following ballot position for
draft-ietf-httpbis-early-hints-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-early-hints/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The document contains the following text: "a server might refrain from sending
Early Hints over HTTP/1.1 unless the client is known to handle informational
responses correctly."  This supposition does not indicate how a server might
know this, and therefore implies that servers should engage in user-agent
sniffing for guessing feature support. User-agent string sniffing is a
well-known anti-pattern, and not one that we should be encouraging.

My recommendation would be inserting an indication in the request to indicate
client support of the 103 status code, which would serve the dual purpose of
avoiding the issues discussed in the Security section as well as not taking up
unnecessary bandwidth for the 103 itself when its contents will go unused.

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 4 Aug 2017 11:31:21 +0900

> https://datatracker.ietf.org/doc/draft-ietf-httpbis-early-hints/

Thank you for your comment.

Use of a request header for negotiation is not a good idea, since HTTP
headers are typically end-to-end.

Consider the case where a proxy that cannot correctly handle an
informational response is involved. If the client sets a HTTP header
indicating that it is capable of receiving 103, the proxy will simply
pass through the header. Therefore, it would become a false signal to
the server.

OTOH it is true that there is a hop-by-hop mechanism in HTTP/1.1.
However, we need to update every proxy to be aware of the new signal
if we need to use a hop-by-hop header. Requiring an update on every
proxy (due to the existence of some buggy implementations) will not be
a wise move.

Considering these aspects, and that most websites that care about
performance will be using HTTP/2 anyways, I think that just leaving a
cautious note here would be sufficient.

-- 
Kazuho Oku

---

From: Adam Roach <[email-masked]>
Date: Sat, 5 Aug 2017 14:26:01 -0500

> pass through the header. Therefore, it would become a false signal to

Thanks for the explanation. This seems reasonable. I'm still a bit 
uneasy about the implied encouragement to user-agent-string sniffing, 
but the intended status of "experimental" makes me worry about it much 
less than I would otherwise. Hopefully, we can learn from this 
experiment how pervasive incorrect handing of 100-class responses in 
general is for HTTP clients.

/a

---

From: Julian Reschke <[email-masked]>
Date: Sat, 5 Aug 2017 22:07:08 +0200

> general is for HTTP clients.

Quite pervasive. See, for instance, 
<http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8170305>.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 6 Aug 2017 07:02:19 +0200

> <http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8170305>.

At least fixing broken existing code is not hard thanks to 100 having
been present for a long time, for example here :

   http://git.haproxy.org/?p=haproxy.git;a=commit;h=a14ad72

:-)

Willy