Opened 10 years ago
Closed 10 years ago
#414 closed design (fixed)
Message Parsing Strictness
Reported by: | mnot@… | Owned by: | draft-ietf-httpbis-p1-messaging@… |
---|---|---|---|
Priority: | normal | Milestone: | 22 |
Component: | p1-messaging | Severity: | In WG Last Call |
Keywords: | Cc: |
Description
3.5 Message Parsing Robustness -- "When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed above, the server must respond with an HTTP/1.1 400 (Bad Request) response." This makes several existing implementations non-conformant (because they silently digest whitespace in those empty lines). See also the issue above about Tolerant Applications and SP/HT in the top-line.
Change History (3)
comment:1 Changed 10 years ago by fielding@…
- Milestone changed from unassigned to 22
- Resolution set to incorporated
- Status changed from new to closed
comment:2 Changed 10 years ago by mnot@…
- Resolution incorporated deleted
- Status changed from closed to reopened
comment:3 Changed 10 years ago by mnot@…
- Resolution set to fixed
- Status changed from reopened to closed
Note: See
TracTickets for help on using
tickets.
From [2028]:
Expand on message parsing robustness regarding whitespace. Clarify that whitespace-delimited parsing by recipients is allowed.
Add requirement on recipients of whitespace between start-line and first header field to be consistent with implementations and safe from the header spoofing issues.
Reduce ABNF conformance by recipients to a SHOULD.
Addresses #411, #412, and #414