Opened 10 years ago
Closed 10 years ago
#409 closed design (fixed)
is parsing OBS-FOLD mandatory?
Reported by: | mnot@… | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 22 |
Component: | p1-messaging | Severity: | In WG Last Call |
Keywords: | Cc: |
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 (17)
comment:1 Changed 10 years ago by mnot@…
comment:2 Changed 10 years ago by mnot@…
- Severity changed from Active WG Document to In WG Last Call
comment:3 Changed 10 years ago by mnot@…
- Owner changed from draft-ietf-httpbis-p1-messaging@… to mnot@…
comment:4 Changed 10 years ago by fielding@…
comment:5 Changed 10 years ago by fielding@…
- Milestone changed from unassigned to 22
- Resolution set to incorporated
- Status changed from new to closed
comment:6 Changed 10 years ago by mnot@…
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 10 years ago by fielding@…
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 10 years ago by mnot@…
- Resolution incorporated deleted
- Status changed from closed to reopened
comment:9 Changed 10 years ago by mnot@…
- Milestone changed from 22 to unassigned
comment:10 Changed 10 years ago by mnot@…
- 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 10 years ago by mnot@…
- Owner mnot@… deleted
- Status changed from reopened to new
comment:12 Changed 10 years ago by fielding@…
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 10 years ago by fielding@…
comment:14 Changed 10 years ago by fielding@…
- Resolution set to incorporated
- Status changed from new to closed
comment:15 Changed 10 years ago by mnot@…
WFM.
comment:16 Changed 10 years ago by mnot@…
- Resolution incorporated deleted
- Status changed from closed to reopened
comment:17 Changed 10 years ago by mnot@…
- Resolution set to fixed
- Status changed from reopened to closed
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