IETF Logo Mail Archive

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

Willy Tarreau <w@1wt.eu> Sun, 25 June 2017 10:46 UTC

Return-Path: <w@1wt.eu>
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 AB10D126CD8; Sun, 25 Jun 2017 03:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 iaGqcBWThPmc; Sun, 25 Jun 2017 03:46:36 -0700 (PDT)
Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6FB120227; Sun, 25 Jun 2017 03:46:35 -0700 (PDT)
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5PAkTTa029029; Sun, 25 Jun 2017 12:46:29 +0200
Date: Sun, 25 Jun 2017 12:46:29 +0200
From: Willy Tarreau <w@1wt.eu>
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, ietf-http-wg@w3.org, alexey.melnikov@isode.com
Subject: Re: Last Call: <draft-ietf-httpbis-early-hints-03.txt> (An HTTP Status Code for Indicating Hints) to Experimental RFC
Message-ID: <20170625104629.GA29021@1wt.eu>
References: <149806437201.15854.12299810594896460001.idtracker@ietfa.amsl.com> <dcdff226-e12d-bb83-982f-8253f46ae935@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <dcdff226-e12d-bb83-982f-8253f46ae935@gmx.de>
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/O3nbCxfxKAFje3oHBLumrxz8tl4>
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:46:39 -0000

Hi Julian,

On Sun, Jun 25, 2017 at 12:11:29PM +0200, Julian Reschke wrote:
>    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)

Not completely. An intermediary not aware of 103 may map it to 100. If
the intermediary inserted an "Expect: 100 continue" header field, we
can reasonably imagine that such an intermediary might also drop the
returning 103. This wording in 7231 may even encourage some implementations
to do so : "A proxy MUST forward 1xx responses unless the proxy itself
requested the generation of the 1xx response". Speaking about 1xx here
may be read as "I asked for 100, I'm receiving 1xx so that matches".

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

If we imagine that clients ignore 103 or that intermediaries occasionally
drop it, I think it's desirable to send them. Said differently, the 103
response prepends a copy of the Link header fields that the final response
is supposed to present to help the client fetch them earlier.

Regards,
Willy

v2.23.0 | Report a Bug | By Email