ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-httpbis-early-hints-03.txt> (An HTTP Status Code for Indicating Hints) to Experimental RFC

2017-06-26 11:41:07
On 06/26/2017 04:36 AM, Julian Reschke wrote:
On 2017-06-26 04:39, Kazuho Oku wrote:
2017-06-25 19:11 GMT+09:00 Julian Reschke 
<julian(_dot_)reschke(_at_)gmx(_dot_)de>:
On 2017-06-21 18:59, The IESG wrote:
    <draft-ietf-httpbis-early-hints-03.txt> as Experimental RFC


For hop-by-hop, I'm not convinced that the requirement is needed here.

Prohibiting hop-by-hop fields is not only unneeded, it is harmful.


The reasons I added a clause prohibiting the use of hop-by-hop headers
in an 103 response are as follows:

* does not make sense for a response that attempts to send the
metadata of a final response early

Those hop-by-hop headers may have nothing to do with the 103 purpose
itself. They may make sense for authentication, tracking, logging, and
many other reasons specific to the deployment environment. As an extreme
example, consider a client that rejects all responses unless they have a
X-Hop-ID hop-by-hop header field. There is no reason to preclude such
client from using the new 103 feature!


* to avoid confusion caused by sending a hop-by-hop header in the 103
response

Adding unrelated restrictions creates even more confusion and bugs. Yes,
hop-by-hop headers can be misused, but early hints is not about
combating all world evils. A new protocol feature should not affect
standard behaviors unless such changes are absolutely necessary for that
feature functionality. If correct usage of some hop-by-hop headers does
not hurt early responses, then we should not prohibit all hop-by-hop
headers.


Without the restriction, a response like below would be valid, which
IMO is confusing at least.

HTTP/1.1 103 Early Hints
Connection: close
Link: </style.css>; rel=preload

HTTP/1.1 200 OK
Connection: close
Link: </style.css>; rel=preload

The same can be said about 100 Continue and other 1xx responses. The
early response feature is not the place to address this confusion.


    An intermediary MAY drop the informational response. (...)

That seems to contradict a MUST-level requirement in RFC 7231
(https://www.greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.2.p.3)

The statement exists since sending 103 only makes sense when it is
impossible to immediately send a final response.

The "only" part of that assertion is too restrictive AFAICT. I can
imagine situations where sending 103 immediately before the final
response makes sense, especially when an intermediary is generating 103s
but does not want to fiddle with final responses.


Considering the facts, one way to resolve the issue would be to adjust
the statement to something like "An intermediary MAY omit the 103
response when resending a cached response", and argue that re-sending
a cached response is not an action of "forwarding," which is defined
as a MUST in RFC 7231.

Sounds good to me.

When a caching intermediary attempts to validate a previously cached
object and suddenly receives a 103 response, the intermediary does not
yet know whether the cached object is still valid/fresh. Thus, if we
require the intermediary to base its 103 forwarding decision on the
cached object state, such an intermediary would have to store the 103
message until the final response is received. That new storage
requirement creates a significant burden for intermediaries!

IMHO, new 1xx messages should not introduce new storage/forwarding
requirements that depend on future final response status. An old caching
proxy should not violate the new 103 specs by default.

Perhaps the proxy-initiated cache validation transaction can be
considered a transaction between the proxy and the server, with no
"forwarding" involved? In that case, the 103 response is directed at the
proxy itself, and any forwarding rules do not apply! The proxy may, at
its own discretion, generate its own 103 response to the client, of
course. That generation may look like forwarding to an outside observer,
but it is not subject to forwarding requirements.


But wouldn't it be simpler to just have the "MAY drop" clause for any
intermediary?

In that case, the spec would contradict RFC 7231, which is bad position
to be in...

Agreed.


The example suggests that early hints are repeated in the final
response. Do they have to, actually?

Yes. They need to, especially if caching is involved. 103 is an
intermediary response and there is no guarantee (or a requirement) for
a cache to retain the headers included only in the informational
response.

In case of link rel=preload headers, a client can speculatively load
the resources included in the headers while revalidating a
stale-cached response, or a caching proxy can generate a 103 response
from a stale-cached 200 response, while waiting for the origin to
perform revalidation.

What I'm after is a clear statement whether they really need to be
repeated, as normative language.
 Based on the discussion, I think it should be the 103 sender decision,
not a protocol-level requirement. I can imagine cases where the final
response should omit some 103 details because the situation has changed
since that 103 was generated. The client should not be required to pay
attention to 103, and the server should not be required to duplicate 103
info.

   A client MUST NOT interpret the 103 (Early Hints)
   response header fields as if they applied to the informational
   response itself

This requirement seems too broad -- a client that does not know about
103s may certainly apply the received 103 header fields to that 103
message. Yes, such a client would make an exception for Content-Length
and similar headers as already required for 1xx handling, but it seems
wrong to place _additional_ MUST-level requirements on an unsuspecting
client.


Overall, it feels like hints should be relayed using a mechanism that
does not abuse existing headers so that there is a clear separation
between the 103 message itself and the hints about the future message.
1xx responses cannot have a body, but perhaps these hints can be encoded
into a new header field? For example:

    HTTP/1.1 103 Hints
    Hints: <encoded Link and other fields here>
    Via: ...
    X-Hop-ID: ...
    Connection: X-Hop-ID


Thank you,

Alex.

<Prev in Thread] Current Thread [Next in Thread>