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

2017-08-02 8:19 GMT+09:00 Adam Roach <adam@nostrum.com>:
> 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.

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

Received on Friday, 4 August 2017 02:31:45 UTC