* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #340 (closed design: wontfix)

Opened 3 years ago

Last modified 2 years ago

Tolerating CR

Reported by: mnot@pobox.com Owned by: draft-ietf-httpbis-p1-messaging@tools.ietf.org
Priority: normal Milestone: unassigned
Component: p1-messaging Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/20120126155637.GA11227@1wt.eu

Description

3.5. Message Parsing Robustness

Likewise, although the line terminator for the start-line and header fields is the sequence CRLF, we recommend that recipients recognize a single LF as a line terminator and ignore any CR.

Does this mean that CR CR CR CR CR CR LF should be interpreted as a single LF ? It kinds of scares me on the risk of smuggling attacks. I'd rather suggest :

... we recommend that recipients recognize a single LF as a line terminator and ignore the optional preceeding CR. Messages containing a CR not followed by an LF MUST be rejected.

Change History

comment:1 Changed 3 years ago by fielding@gbiv.com

There is no risk of smuggling because no implementation treats CR as a line terminator (which is the whole point of including that prose in the spec). CR is just whitespace. Remember, we are not changing the protocol. Requiring CR be rejected would be an incompatible change.

comment:2 Changed 3 years ago by mnot@pobox.com

Yes, the proposal currently on-list is:

Likewise, although the line terminator for the start-line and header fields is the sequence CRLF, we recommend that recipients recognize a single LF as a line terminator and ignore the preceding CR, if present.

Note that the 'reject' language has been removed.

This is an improvement because the current language says "any CR", which can be interpreted in a few different ways.

"...ignore any preceding CR." (not the) would also work, I think.

Note that we currently don't define CR as whitespace; is your intent to only consider CR at the end of a line as whitespace, leaving it undefined / unhandled elsewhere?

comment:3 Changed 3 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 19

comment:4 Changed 2 years ago by julian.reschke@gmx.de

  • Milestone changed from 19 to unassigned

comment:5 Changed 2 years ago by mnot@pobox.com

Discussed in Paris; general feeling was that this could be closed with no action, as CR alone isn't valid, we don't define error-handling behaviours in all cases, and there isn't a smuggling attack here.

comment:6 Changed 2 years ago by mnot@pobox.com

  • Status changed from new to closed
  • Resolution set to wontfix
Note: See TracTickets for help on using tickets.