IETF Logo Mail Archive

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

Julian Reschke <julian.reschke@gmx.de> Sun, 25 June 2017 10:11 UTC

Return-Path: <julian.reschke@gmx.de>
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 90A92129462; Sun, 25 Jun 2017 03:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Level:
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 0uBS7ynBqZFg; Sun, 25 Jun 2017 03:11:41 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 5A3321242F5; Sun, 25 Jun 2017 03:11:38 -0700 (PDT)
Received: from [192.168.178.20] ([93.217.96.65]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MNIAz-1dR0SA0zwP-006ykk; Sun, 25 Jun 2017 12:11:31 +0200
Subject: Re: Last Call: <draft-ietf-httpbis-early-hints-03.txt> (An HTTP Status Code for Indicating Hints) to Experimental RFC
To: ietf@ietf.org
Cc: httpbis-chairs@ietf.org, Mark Nottingham <mnot@mnot.net>, draft-ietf-httpbis-early-hints@ietf.org, ietf-http-wg@w3.org, alexey.melnikov@isode.com
References: <149806437201.15854.12299810594896460001.idtracker@ietfa.amsl.com>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <dcdff226-e12d-bb83-982f-8253f46ae935@gmx.de>
Date: Sun, 25 Jun 2017 12:11:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <149806437201.15854.12299810594896460001.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:TxAO1g1ckcQ1IgCGXt5jOqL2bnyoR6hoftTQkPw9Di0QaMxLl1m XzZ+AA3I0L0zmv6EA/DZbrTeGfUbvKRTrIm8h+BnHyZPU8PYEADuyAW9VjKasIdMlulBRzc 5/ZMXNNW0jd58V31qFuorYqGw7jXNrVhmby+ivXSvGxeRrq/5DY3mz/Dq7GmXiEDonMW33K HL3URfUidkkjtm6H5XE2g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:uaD7ch7hzj8=:8xj7/07D+PHyV+EPlaZZUN 2bJNfgd0OQKECnbcUZ9ESTm743yGO4GFp9LDjLvvKTCSl3FMb0Wceul4OK8ad90C62bwLo5Ep wL4o7yfaD7F6jzXVxdTc17pNPoIbZN2QViAsOlzpSvwEqQKaYt9qjNdlwdvdYiMb3kEXxdhCs RfDKOxRD2cZicxzRb8m8ok2zDjmYTEHhAaucE4xYuUz8vgkrm7P1yLyf3LUR1fQxZNH+frRxY AoJpEiRNNXonJQDQYfbgWEjjC6CYnHd2Zifh8uLOslSCfVcyPmFs1L/eIcSBCqPLEoIGxQTyF w3K/vHnpyN74jym11wyNT6WEk7+EE7w4eEsokFCy88bzrM2JsbmsbM2kKfHjAM3epBL2VVaB/ qCOOhGAW7pZ3Q1PqKlp8sI+X/UpK0HkGyhiX03GCRYq5gM+vGUiJdF7NdaBARvyJoqRNEK0JQ u/9UwtLrN87TCZ4eL6w7S402qE+qA73Dq5IpGInc1ysVJe7+G4wZOVkIFkSvdvsZQokgEJtfN ouLTaE+9CuYOWkcXuoqFGkIeIE1sNQt4vwGhv6NMP3rEdm6ceW7lJ40d576AYsPT3ls2X4dVT /XHx83vdpa6qiGLyPAmI8Vdz0vKZo9u81h5DFGs6k355g/6fR6M/OtY5Tdhjj+yTQ3yCsjnwO 7TzsU2lwWFr4BAd8ybw8JbjqJ0l1W4f3eDEIs0S8eZvt58HgJFade2jlxNtwGsAInlwQmSDtP L3DbmAmm4nbndCqGwUdKI0FboM1yRt0iNsk7huSZuy8vvlQAOZ/kZsCUFGB7usP1clu3pacf2 6Gc1eZ+
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/rVwe407uNI7IWcUxLYeRoYEBL6k>
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: Sun, 25 Jun 2017 10:11:44 -0000

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.

    ...

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


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

v2.23.0 | Report a Bug | By Email