Changeset 2593
- Timestamp:
- 28/01/14 00:44:14 (8 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2592 r2593 2353 2353 </p> 2354 2354 <div id="rfc.figure.u.61"></div> 2355 <p> Thus, a sender <em class="bcp14">MUST</em> expand the list construct as follows:2355 <p>In any production that uses the list construct, a sender <em class="bcp14">MUST NOT</em> generate empty list elements. In other words, a sender <em class="bcp14">MUST</em> generate lists that satisfy the following syntax: 2356 2356 </p><pre class="text"> 1#element => element *( OWS "," OWS element ) 2357 2357 </pre><div id="rfc.figure.u.62"></div> … … 2360 2360 <p>and for n >= 1 and m > 1:</p><pre class="text"> <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) 2361 2361 </pre><p id="rfc.section.7.p.6">For compatibility with legacy list rules, a recipient <em class="bcp14">MUST</em> parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, 2362 but not so much that they could be used as a denial of service mechanism. In other words, a recipient <em class="bcp14">MUST</em> expand the list construct as follows:2362 but not so much that they could be used as a denial of service mechanism. In other words, a recipient <em class="bcp14">MUST</em> accept lists that satisfy the following syntax: 2363 2363 </p> 2364 2364 <div id="rfc.figure.u.64"></div><pre class="text"> #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] … … 2378 2378 "," 2379 2379 ", ," 2380 </pre><p id="rfc.section.7.p.14"><a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF after the list constructs have been expanded, as described above, for recipients.2380 </pre><p id="rfc.section.7.p.14"><a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF for recipients after the list constructs have been expanded. 2381 2381 </p> 2382 2382 </div> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2592 r2593 3313 3313 <section title="ABNF list extension: #rule" anchor="abnf.extension"> 3314 3314 <t> 3315 A #rule extension to the ABNF rules of <xref target="RFC5234"/> is used to3316 improve readability in the definitions of some header field values.3317 </t> 3318 <t> 3319 A construct "#" is defined, similar to "*", for defining comma-delimited3320 lists of elements. The full form is "<n>#<m>element" indicating3321 at least <n> and at most <m> elements, each separated by a single3322 comma (",") and optional whitespace (OWS).3315 A #rule extension to the ABNF rules of <xref target="RFC5234"/> is used to 3316 improve readability in the definitions of some header field values. 3317 </t> 3318 <t> 3319 A construct "#" is defined, similar to "*", for defining comma-delimited 3320 lists of elements. The full form is "<n>#<m>element" indicating 3321 at least <n> and at most <m> elements, each separated by a single 3322 comma (",") and optional whitespace (OWS). 3323 3323 </t> 3324 3324 <figure><preamble> 3325 Thus, a sender &MUST; expand the list construct as follows: 3325 In any production that uses the list construct, a sender &MUST-NOT; 3326 generate empty list elements. In other words, a sender &MUST; generate 3327 lists that satisfy the following syntax: 3326 3328 </preamble><artwork type="example"> 3327 3329 1#element => element *( OWS "," OWS element ) 3328 3330 </artwork></figure> 3329 3331 <figure><preamble> 3330 and:3332 and: 3331 3333 </preamble><artwork type="example"> 3332 3334 #element => [ 1#element ] 3333 3335 </artwork></figure> 3334 3336 <figure><preamble> 3335 and for n >= 1 and m > 1:3337 and for n >= 1 and m > 1: 3336 3338 </preamble><artwork type="example"> 3337 3339 <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) 3338 3340 </artwork></figure> 3339 3341 <t> 3340 For compatibility with legacy list rules, a recipient &MUST; parse and ignore3341 a reasonable number of empty list elements: enough to handle common mistakes3342 by senders that merge values, but not so much that they could be used as a3343 denial of service mechanism. In other words, a recipient &MUST; expand the3344 list construct as follows:3342 For compatibility with legacy list rules, a recipient &MUST; parse and ignore 3343 a reasonable number of empty list elements: enough to handle common mistakes 3344 by senders that merge values, but not so much that they could be used as a 3345 denial of service mechanism. In other words, a recipient &MUST; accept lists 3346 that satisfy the following syntax: 3345 3347 </t> 3346 3348 <figure><artwork type="example"> … … 3350 3352 </artwork></figure> 3351 3353 <t> 3352 Empty elements do not contribute to the count of elements present.3353 For example, given these ABNF productions:3354 Empty elements do not contribute to the count of elements present. 3355 For example, given these ABNF productions: 3354 3356 </t> 3355 3357 <figure><artwork type="example"> … … 3358 3360 </artwork></figure> 3359 3361 <t> 3360 Then the following are valid values for example-list (not including the3361 double quotes, which are present for delimitation only):3362 Then the following are valid values for example-list (not including the 3363 double quotes, which are present for delimitation only): 3362 3364 </t> 3363 3365 <figure><artwork type="example"> … … 3367 3369 </artwork></figure> 3368 3370 <t> 3369 In contrast, the following values would be invalid, since at least one3370 non-empty element is required by the example-list production:3371 In contrast, the following values would be invalid, since at least one 3372 non-empty element is required by the example-list production: 3371 3373 </t> 3372 3374 <figure><artwork type="example"> … … 3376 3378 </artwork></figure> 3377 3379 <t> 3378 <xref target="collected.abnf"/> shows the collected ABNF after the list3379 constructs have been expanded, as described above, for recipients.3380 <xref target="collected.abnf"/> shows the collected ABNF for recipients 3381 after the list constructs have been expanded. 3380 3382 </t> 3381 3383 </section>
Note: See TracChangeset
for help on using the changeset viewer.