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

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 <>:
>>> 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

>> 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
>>> (

>> 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...


>>> 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

>    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

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,


Received on Monday, 26 June 2017 16:41:17 UTC