[Errata Held for Document Update] RFC7230 (5163)

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

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

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: David Matson <dmatson@microsoft.com>
Date Reported: 2017-10-20
Held by: Francesca Palombini (IESG)

Section: 3.2.4

Original Text
-------------
A field value might be preceded and/or followed by optional
whitespace (OWS); a single SP preceding the field-value is preferred
for consistent readability by humans.  The field value does not
include any leading or trailing whitespace: OWS occurring before the
first non-whitespace octet of the field value or after the last
non-whitespace octet of the field value ought to be excluded by
parsers when extracting the field value from a header field.


Corrected Text
--------------
A field value might be preceded and/or followed by optional
whitespace (OWS); a single SP preceding the field-value is preferred
for consistent readability by humans.  The field value does not
include any leading or trailing whitespace: OWS occurring before the
first non-whitespace octet of the field value or after the last
non-whitespace octet of the field value ought to be excluded by
parsers when extracting the field value from a header field.

All optional whitespace between tokens in field-content has the same
semantics as SP. Any sequence of SP / HTAB that occurs between tokens
in field-content MAY be replaced with a single SP before interpreting
the field value or forwarding the message downstream.

Notes
-----
RFC 2616, section 2.2, contained the following text:

All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.

Similarly, RFC 2616 section 4.2 contained the following text:
Any LWS that occurs between field-content MAY be replaced with a single SP before interpreting the field value or forwarding the message downstream.

In section A.2. Changes from RFC 2616, the document does not list any intended change for how space and tab are handled, but the current text does appear to constitute a change. I suspect the change is accidental due to rewording the document when line folding was made deprecated.

Note that in RFC 2616, LWS is defined as follows:
LWS            = [CRLF] 1*( SP | HT )

In particular, the leading CRLF was optional.

Thus, the wording in RFC 2616 covered two cases:
1. LWS that includes line folding.
2. LWS that does not include line folding.

The current text does cover how to handle case #1 - former LWS that began with a CRLF; later in section 3.2.4 it requires rejecting or replacing with SP. (The old "MAY" language has effectively become a "MUST" for the leading CRLF case.)

However, the current text does not appear to address case #2 - former LWS that does not begin with a CRLF - in other words, SP and HTAB occurring between field-content. I suspect the intention is still that a recipient should treat such whitespace as insignificant, and may replace any sequence of SP and HTAB with a single SP before interpreting the field content, but I believe the text of the current RFC no longer provides this behavior.

(I have not read all of the specifications in full, so please accept my apologies if I have misread or missed a relevant portion elsewhere.)

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

Received on Monday, 23 August 2021 16:31:11 UTC