Re: [Technical Errata Reported] RFC7233 (4682)

[Julian Reschke <[e-mail]>]

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 <[e-mail]>
>
> 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