Re: [Technical Errata Reported] RFC7233 (4682)

My mistake again, sorry!

It looks like I used the first definition of "1#element", intended for producers, instead of the second definition, intended for consumers.

On Tue, May 3, 2016 at 11:51 PM, Julian Reschke <julian.reschke@greenbytes.de <mailto:julian.reschke@greenbytes.de>> wrote:
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 <http://www.rfc-editor.org/errata_search.php?rfc=7233&eid=4682>

--------------------------------------
Type: Technical
Reported by: Kannan Goundan <kannan@cakoose.com <mailto: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 <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 <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 <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