RFC Errata
RFC 7230, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", June 2014
Note: This RFC has been obsoleted by RFC 9110, RFC 9112
Note: This RFC has been updated by RFC 8615
Source of RFC: httpbis (wit)
Errata ID: 5163
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: David Matson
Date Reported: 2017-10-20
Held for Document Update by: Francesca Palombini
Date Held: 2021-08-23
Section 3.2.4 says:
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.
It should say:
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.)