[Errata Rejected] RFC7230 (5599)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 15 April 2019 14:06 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240F9120187 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 15 Apr 2019 07:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.9
X-Spam-Level:
X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=unavailable 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 3EzO73ZoFp9u for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 15 Apr 2019 07:06:20 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D381200B1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 15 Apr 2019 07:06:20 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hG2D3-0005Xo-2P for ietf-http-wg-dist@listhub.w3.org; Mon, 15 Apr 2019 14:03:45 +0000
Resent-Date: Mon, 15 Apr 2019 14:03:45 +0000
Resent-Message-Id: <E1hG2D3-0005Xo-2P@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <wwwrun@rfc-editor.org>) id 1hG2D0-0005XB-TW for ietf-http-wg@listhub.w3.org; Mon, 15 Apr 2019 14:03:42 +0000
Received: from rfc-editor.org ([4.31.198.49]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <wwwrun@rfc-editor.org>) id 1hG2Cj-00077R-Ew for ietf-http-wg@w3.org; Mon, 15 Apr 2019 14:03:40 +0000
Received: by rfc-editor.org (Postfix, from userid 30) id 54116B80675; Mon, 15 Apr 2019 07:02:55 -0700 (PDT)
To: mvjames@ieee.org, fielding@gbiv.com, julian.reschke@greenbytes.de
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: aamelnikov@fastmail.fm, iesg@ietf.org, ietf-http-wg@w3.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20190415140255.54116B80675@rfc-editor.org>
Date: Mon, 15 Apr 2019 07:02:55 -0700
Received-SPF: pass client-ip=4.31.198.49; envelope-from=wwwrun@rfc-editor.org; helo=rfc-editor.org
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: AWL=1.018, BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1hG2Cj-00077R-Ew 62858909bc3f3632a1ec68df160facf9
X-Original-To: ietf-http-wg@w3.org
Subject: [Errata Rejected] RFC7230 (5599)
Archived-At: <https://www.w3.org/mid/20190415140255.54116B80675@rfc-editor.org>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36530
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

The following errata report has been rejected for RFC7230,
"Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5599

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Michael James <mvjames@ieee.org>
Date Reported: 2019-01-13
Rejected by: Alexey Melnikov (IESG)

Section: GLOBAL

Original Text
-------------
2.3.  Intermediaries 
...
   HTTP is defined as a stateless protocol, meaning that each request
   message can be understood in isolation.  Many implementations depend
   on HTTP's stateless design in order to reuse proxied connections or
   dynamically load balance requests across multiple servers.  Hence, a
   server MUST NOT assume that two requests on the same connection are
   from the same user agent unless the connection is secured and
   specific to that agent.

2.5.  Conformance and Error Handling
...
   A recipient MUST interpret a received protocol element according to
   the semantics defined for it by this specification, including
   extensions to this specification, unless the recipient has determined
   (through experience or configuration) that the sender incorrectly
   implements what is implied by those semantics.  For example, an
   origin server might disregard the contents of a received
   Accept-Encoding header field if inspection of the User-Agent header
   field indicates a specific implementation version that is known to
   fail on receipt of certain content codings.
...

2.6.  Protocol Versioning
...
   A server MAY send an HTTP/1.0 response to a request if it is known or
   suspected that the client incorrectly implements the HTTP
   specification and is incapable of correctly processing later version
   responses, such as when a client fails to parse the version number
   correctly or when an intermediary is known to blindly forward the
   HTTP-version even when it doesn't conform to the given minor version
   of the protocol.  Such protocol downgrades SHOULD NOT be performed
   unless triggered by specific client attributes, such as when one or
   more of the request header fields (e.g., User-Agent) uniquely match
   the values sent by a client known to be in error.
...

Corrected Text
--------------
2.3.  Intermediaries 
...
   HTTP is defined as a stateless protocol, meaning that each request
   message can be understood in isolation.  Many implementations depend
   on HTTP's stateless design in order to reuse proxied connections or
   dynamically load balance requests across multiple servers.  Hence, a
   server MUST NOT assume that two requests on the same connection are
   from the same user agent unless the connection is secured and
   specific to that agent. User agents MUST include a User-Agent
   request-header field with CONNECT and individual query requests that
   uniquely identify the product making the request thru an
   intermediary.

2.5.  Conformance and Error Handling
...
   A recipient MUST interpret a received protocol element according to
   the semantics defined for it by this specification, including
   extensions to this specification, unless the recipient has determined
   (through experience or configuration) that the sender incorrectly
   implements what is implied by those semantics.  For example, an
   origin server might disregard the contents of a received
   Accept-Encoding header field if inspection of the User-Agent header
   field indicates a specific implementation version that is known to
   fail on receipt of certain content codings. User agents MUST 
   include a User-Agent request-header field with CONNECT and 
   individual query requests that uniquely identify the product
   making the request.
...

2.6.  Protocol Versioning
...
   A server MAY send an HTTP/1.0 response to a request if it is known or
   suspected that the client incorrectly implements the HTTP
   specification and is incapable of correctly processing later version
   responses, such as when a client fails to parse the version number
   correctly or when an intermediary is known to blindly forward the
   HTTP-version even when it doesn't conform to the given minor version
   of the protocol.  Such protocol downgrades SHOULD NOT be performed
   unless triggered by specific client attributes, such as when one or
   more of the request header fields (e.g., User-Agent) uniquely match
   the values sent by a client known to be in error. User agents 
   MUST include a User-Agent request-header field with CONNECT and 
   individual query requests that uniquely identify the product making
   the request.
...

Notes
-----
User agents MUST include a User-Agent 
   request-header field with CONNECT and individual query requests that 
   uniquely identify the product making the request thru an intermediary.

RFC 2616 Sec 14.43 specified made the "User-Agent" request-header as optional "User agents SHOULD include this field with requests." But RFC7230 drops most mentions of the User-Agent request-header field. Without this field intermediaries are left guessing. 


Most of the complaints against including the User-Agent header is the monstrosity they have become an the spoofing. Even if the field only contains a SHA-256 hash of the binary making the request, this would differentiate between processes. But having it is still better from a security and interoperability perceptive.
 --VERIFIER NOTES-- 
   See WG summary at <https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0029.html>

--------------------------------------
RFC7230 (draft-ietf-httpbis-p1-messaging-26)
--------------------------------------
Title               : Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
Publication Date    : June 2014
Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
Category            : PROPOSED STANDARD
Source              : Hypertext Transfer Protocol Bis APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG