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

Ticket #409 (closed design: fixed)

Opened 23 months ago

Last modified 17 months ago

is parsing OBS-FOLD mandatory?

Reported by: mnot@pobox.com Owned by:
Priority: normal Milestone: 22
Component: p1-messaging Severity: In WG Last Call
Keywords: Cc:
Origin: http://www.w3.org/mid/DAED760B-AC6A-44A6-816C-59EEEF705E4E@mnot.net

Description

2.5 Conformance and Error Handling says "...recipient MUST be able to parse any value that would match the ABNF rules..." yet 3.2.2 only make parsing obs-fold a SHOULD. Which is it?

Change History

comment:1 Changed 23 months ago by mnot@pobox.com

In Atlanta:

rf: if you can find no interoperable folding implementations, then we can remove it from the grammar [[scribe: may not have got this right, action more important to capture]] ACTION: mnot to run some tests on folding to understand its interoperability

comment:2 Changed 23 months ago by mnot@pobox.com

  • Severity changed from Active WG Document to In WG Last Call

comment:3 Changed 22 months ago by mnot@pobox.com

  • Owner changed from draft-ietf-httpbis-p1-messaging@tools.ietf.org to mnot@pobox.com

comment:4 Changed 22 months ago by fielding@gbiv.com

From [2039]:

Parsing obs-fold is necessary for backwards compat; addresses #409

comment:5 Changed 22 months ago by fielding@gbiv.com

  • Status changed from new to closed
  • Resolution set to incorporated
  • Milestone changed from unassigned to 22

comment:6 Changed 22 months ago by mnot@pobox.com

I thought the approach we were going to take here was to modify the overall requirement regarding syntax conformance to exempt the obs-* constructs, rather than un-deprecate obs-fold...

comment:7 Changed 22 months ago by fielding@gbiv.com

We could still do that, but I needed to make the existing text consistent first.

Note that we still need to discuss such a change on list.

comment:8 Changed 22 months ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

Deprecating line-folding was an explicit decision of the WG in #77; see [395].

[2039] effectively reverts that decision. Taking to list.

comment:9 Changed 22 months ago by mnot@pobox.com

  • Milestone changed from 22 to unassigned

comment:10 Changed 21 months ago by mnot@pobox.com

  • Milestone changed from unassigned to 22

Proposal:

""" Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type (Section 7.3.1). Senders MUST NOT generate messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the message is intended for packaging within the message/http media type. Recipients MUST either:

  • accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream, or
  • reject a message with line folding present. Servers can do for requests by responding with 400 Bad Request and a representation explaining the condition; clients can only discard the message.

In particular, recipients who choose not to implement obs-fold processing (as described above) MUST NOT accept messages containing headers with leading whitespace, as this can expose them to attacks that exploit this difference in processing. """

comment:11 Changed 21 months ago by mnot@pobox.com

  • Owner mnot@pobox.com deleted
  • Status changed from reopened to new

comment:12 Changed 21 months ago by fielding@gbiv.com

It isn't possible for clients to simply discard a message, since responses are queued. I will commit a slight variation of the above.

comment:13 Changed 21 months ago by fielding@gbiv.com

From [2146]:

Allow recipients to reject obsolete line folding; addresses #409

comment:14 Changed 21 months ago by fielding@gbiv.com

  • Status changed from new to closed
  • Resolution set to incorporated

comment:15 Changed 21 months ago by mnot@pobox.com

WFM.

comment:16 Changed 17 months ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:17 Changed 17 months ago by mnot@pobox.com

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