IETF Logo Mail Archive

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

Kazuho Oku <kazuhooku@gmail.com> Mon, 26 June 2017 02:39 UTC

Return-Path: <kazuhooku@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7BA12869B; Sun, 25 Jun 2017 19:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmG_KWAWUB90; Sun, 25 Jun 2017 19:39:24 -0700 (PDT)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2971243F3; Sun, 25 Jun 2017 19:39:24 -0700 (PDT)
Received: by mail-pg0-x22a.google.com with SMTP id f127so42056664pgc.0; Sun, 25 Jun 2017 19:39:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pm+/10K7W/yx9xxtrtOgJ+ammek4Ecvf8z5IEUto5dw=; b=vd9bjx9WGIzMtY2d2CAVPMMmQn6baC1S776MMx9F24kPMf0JQo0dDKtfb/IGefz9eL 012luNbUrcHSWztt/nLYGxqhc88wBEiTZr7Y09+PfCWgDPUxDvdYi6R6aaSorolwovCr xFSClPWsNdFIpVpWomNgxPTVJiBmRzh+uD4A5t8nb18skti5M4vfWpGNNhiQQJ4v1sh/ T3eEH9QVAzCw9lz3sTEbjRAc3itCUtnGr0HkK7rV9SCV9ovyGiYW2KQ8t0VW0kT1G+Mh UjNcX3a5XbL/mChqmsPaySiLJ8QB56ZU9gU2Uk4C28oPiDcs6XfAwCmd11zvAKE1GjyD GZEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pm+/10K7W/yx9xxtrtOgJ+ammek4Ecvf8z5IEUto5dw=; b=QL5gDUVLeO3Hc7lav1knS3pF7uFl4T9NVgVFqFGSuiS3WYfxJjIDGhYED6IGdt8iuw jOuUmSzlBsMi63yBDVEtEj3ZirtGs3a5Rnq6yahqylvO6mrOs27EVDD7h/XXtQn0T/xe RNdXDoPnsm7exf70lNQc1oqyIqE9LAndjvGsWiBdjKFrNp4uQ+K+Y6jLZ9cbR9/5H80a lYhT0OdSoQcED4QVH74Q60v5tY9J2+275EYkPtJ4epxiTRw2CT36TRsg7eXb//L8kQVv DFnon1Ztr5OJfCxV4B0SJgf68Qa4NDl/kBszGBNi6gwTxjLsRYZ9tnsflgHyW1S5ay4j yJ1A==
X-Gm-Message-State: AKS2vOxhrWOdkDgR1G+IAbbaVAWSaBEV5T/ffxZpTiiQlYJK753h49HF aX4HnogfLErP+eElTfnLLOW4Z5VAdw==
X-Received: by 10.84.198.129 with SMTP id p1mr16997120pld.120.1498444763788; Sun, 25 Jun 2017 19:39:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.130.3 with HTTP; Sun, 25 Jun 2017 19:39:23 -0700 (PDT)
In-Reply-To: <dcdff226-e12d-bb83-982f-8253f46ae935@gmx.de>
References: <149806437201.15854.12299810594896460001.idtracker@ietfa.amsl.com> <dcdff226-e12d-bb83-982f-8253f46ae935@gmx.de>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Mon, 26 Jun 2017 11:39:23 +0900
Message-ID: <CANatvzygaU9oiof3-5TqnWdxqXOGNyGqPvNhTnpPzYy391CzNw@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-httpbis-early-hints-03.txt> (An HTTP Status Code for Indicating Hints) to Experimental RFC
To: Julian Reschke <julian.reschke@gmx.de>
Cc: ietf@ietf.org, httpbis-chairs@ietf.org, Mark Nottingham <mnot@mnot.net>, draft-ietf-httpbis-early-hints@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, alexey.melnikov@isode.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/WaGNJYH2NiP4_62gUxUX0NRpN4k>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jun 2017 02:39:27 -0000

Hi Julian,

Thank you very much for your comments.

I will create a PR fixing the editorial issues. For the other issues,
my responses in-line.

2017-06-25 19:11 GMT+09:00 Julian Reschke <julian.reschke@gmx.de>:
> On 2017-06-21 18:59, The IESG wrote:
>>
>>
>> The IESG has received a request from the Hypertext Transfer Protocol WG
>> (httpbis) to consider the following document: - 'An HTTP Status Code for
>> Indicating Hints'
>>    <draft-ietf-httpbis-early-hints-03.txt> as Experimental RFC
>> ...
>
>
>
> Here's my feedback...:
>
> 2.  103 Early Hints
>
>    ...
>
>    A server MUST NOT include Content-Length, Transfer-Encoding, or any
>    hop-by-hop header fields ([RFC7230], Section 6.1) in a 103 (Early
>    Hints) response.
>
> That's a bit weird here, because the requirements for C-L and T-E are
> generic to 1xx, and already are stated in RFC 7230. The text above makes it
> sound as if these are specific to 103, which they are not.
>
> For hop-by-hop, I'm not convinced that the requirement is needed here.

I agree that we do not need to talk about C-L and T-E here.

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
* to avoid confusion caused by sending a hop-by-hop header in the 103 response

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

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

For example, there is no need for a cache that is in possession of a
freshly-cached final response to send a 103 that was sent from the
origin before sending the final response. I also believe that most
caching proxies that exist today do not cache informational responses,
and that there is no need for us to require them to do so.

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.

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

>    The following example illustrates a typical message exchange that
>    involves a 103 (Early Hints) response.
>
>    Client request:
>
>      GET / HTTP/1.1
>      Host: example.com
>
> (maybe insert blank line do delimit the message)
>
>    Server response:
>
>      HTTP/1.1 103 Early Hints
>      Link: </style.css>; rel=preload; as=style
>      Link: </script.js>; rel=preload; as=script
>
>      HTTP/1.1 200 OK
>      Date: Fri, 26 May 2017 10:02:11 GMT
>      Content-Length: 1234
>      Content-Type: text/html; charset=utf-8
>      Link: </style.css>; rel=preload; as=style
>      Link: </script.js>; rel=preload; as=script
>
>      <!doctype html>
>      [... rest of the response body is ommitted from the example ...]
>
> 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.

>
> 3.  Security Considerations
>
>    Some clients might have issues handling 103 (Early Hints), since
>    informational responses are rarely used in reply to requests not
>    including an Expect header ([RFC7231], Section 5.1.1).
>
> s/header/header field/
>
>    In particular, an HTTP/1.1 client that mishandles an informational
>    response as a final response is likely to consider all responses to
>    the succeeding requests sent over the same connection to be part of
>    the final response.  Such behavior may constitute a cross-origin
>
> s/may/might/ or /can/ (or invoke https://tools.ietf.org/html/rfc8174)
>
>    information disclosure vulnerability in case the client multiplexes
>    requests to different origins onto a single persistent connection.
>
>    ...
>
> 5.  Acknowledgements
>
> Nit: This should be an appendix (the last one).
>
> 6.  Changes
>
> Nit: This should be an appendix.
>
>
> Best regards, Julian



-- 
Kazuho Oku

v2.23.0 | Report a Bug | By Email