- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Wed, 4 May 2016 08:51:08 +0200
- To: RFC Errata System <rfc-editor@rfc-editor.org>, fielding@gbiv.com, ylafon@w3.org, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, mnot@mnot.net
- Cc: kannan@cakoose.com, ietf-http-wg@w3.org
On 2016-05-04 00:41, RFC Errata System wrote: > The following errata report has been submitted for RFC7233, > "Hypertext Transfer Protocol (HTTP/1.1): Range Requests". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7233&eid=4682 > > -------------------------------------- > Type: Technical > Reported by: Kannan Goundan <kannan@cakoose.com> > > Section: 2.1 > > Original Text > ------------- > byte-range-set= 1#( byte-range-spec / suffix-byte-range-spec ) > > Corrected Text > -------------- > According to the "1#element" rule, the expansion would be: > > byte-range-set = ( byte-range-spec / > suffix-byte-range-spec ) *( OWS "," OWS ( byte-range-spec / > suffix-byte-range-spec ) ) > > But Appendix D has the definition: > > byte-range-set = *( "," OWS ) ( byte-range-spec / > suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec / > suffix-byte-range-spec ) ] ) > > > Notes > ----- > This is a followup to my original report: <http://www.rfc-editor.org/errata_search.php?rfc=7233&eid=4681> > > My original report was incorrect because I didn't notice the difference between "1*element" and "1#element". Thanks to Julian Reschke for pointing this out to me. > > After looking up the "1#element" rule <https://tools.ietf.org/html/rfc7230#section-7>, it looks like Section 2.1 and Appendix D are more similar, but not exactly equivalent. > > The Appendix D version of the rule seems to allow extra commas and OWS. > I'm trying to write strict parsing code for this header and am not sure which definition to follow. > > P.S. I hope I didn't screw up again. I apologize for wasting your time (again) if I did. As far as I can tell, this expansion is exactly as defined in <https://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.7.p.3>: > For compatibility with legacy list rules, a recipient MUST parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, but not so much that they could be used as a denial-of-service mechanism. In other words, a recipient MUST accept lists that satisfy the following syntax: > > #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] > > 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) Best regards, Julian
Received on Wednesday, 4 May 2016 06:54:03 UTC