Bare CR in header fields

Hey folks,

I just got around to noticing this text in section 2.2 (Message
Parsing) of the proposed messaging draft as part of last-call review
(https://www.ietf.org/archive/id/draft-ietf-httpbis-messaging-14.html#section-2.2):

> A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the content. A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP before processing the element or forwarding the message.

Out of curiosity I did some investigation, because I'd been shared an
example in the past of a client creating a bare CR as an LF in header
field parsing. My investigation revealed that Safari, Chrome, and
Opera all treat a bare CR as though it were a field line terminator,
and that Firefox appeared to stop parsing at the CR (but use all bytes
prior to that CR in the value).

Why are we specifying a normative requirement to do something no major
implementation appears to do? The web platform tests have an open
issue to add this test
(https://github.com/web-platform-tests/wpt/pull/13524), but so far as
I can see that test as written plans to encode the existing
non-spec-compliant behaviour.

On the original discussion thread on this issue
(https://github.com/httpwg/http-core/issues/31) Roy notes that this
has always been forbidden in HTTP/1.1. While I appreciate that, it is
not terribly helpful for us to specify behaviours that do not reflect
common implementer behaviour.

In particular, I'll note that Roy said, a year and a half ago, "If
some browsers interpret CR as a line delimiter in HTTP protocol fields
(other than payload content), they have security holes that should be
fixed." Is that the position of this working group? Who is
coordinating with these implementations to address that security hole?

Cory

Received on Wednesday, 20 January 2021 21:06:40 UTC