Changeset 1518 for draft-ietf-httpbis/latest
- Timestamp:
- 30/01/12 01:48:21 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1517 r1518 301 301 </t> 302 302 303 <section title=" Conformance and Error Handling" anchor="intro.conformance.and.error.handling">303 <section title="Requirement Notation" anchor="intro.requirements"> 304 304 <t> 305 305 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 306 306 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 307 307 document are to be interpreted as described in <xref target="RFC2119"/>. 308 </t>309 <t>310 This document defines conformance criteria for several roles in HTTP311 communication, including Senders, Recipients, Clients, Servers, User-Agents,312 Origin Servers, Intermediaries, Proxies and Gateways. See <xref target="architecture"/>313 for definitions of these terms.314 </t>315 <t>316 An implementation is considered conformant if it complies with all of the317 requirements associated with its role(s). Note that SHOULD-level requirements318 are relevant here, unless one of the documented exceptions is applicable.319 </t>320 <t>321 This document also uses ABNF to define valid protocol elements322 (<xref target="notation"/>). In addition to the prose requirements placed323 upon them, Senders &MUST-NOT; generate protocol elements that are invalid.324 </t>325 <t>326 Unless noted otherwise, Recipients &MAY; take steps to recover a usable327 protocol element from an invalid construct. However, HTTP does not define328 specific error handling mechanisms, except in cases where it has direct329 impact on security. This is because different uses of the protocol require330 different error handling strategies; for example, a Web browser may wish to331 transparently recover from a response where the Location header field332 doesn't parse according to the ABNF, whereby in a systems control protocol333 using HTTP, this type of error recovery could lead to dangerous consequences.334 308 </t> 335 309 </section> … … 350 324 <t> 351 325 This specification uses the Augmented Backus-Naur Form (ABNF) notation 352 of <xref target="RFC5234"/>. 326 of <xref target="RFC5234"/> with the list rule extension defined in 327 <xref target="abnf.extension"/>. <xref target="collected.abnf"/> shows 328 the collected ABNF with the list rule expanded. 353 329 </t> 354 330 <t anchor="core.rules"> … … 374 350 </t> 375 351 <t> 376 As a syntacticconvention, ABNF rule names prefixed with "obs-" denote352 As a convention, ABNF rule names prefixed with "obs-" denote 377 353 "obsolete" grammar rules that appear for historical reasons. 378 354 </t> 379 380 <section title="ABNF Extension: #rule" anchor="notation.abnf">381 <t>382 The #rule extension to the ABNF rules of <xref target="RFC5234"/> is used to383 improve readability.384 </t>385 <t>386 A construct "#" is defined, similar to "*", for defining comma-delimited387 lists of elements. The full form is "<n>#<m>element" indicating388 at least <n> and at most <m> elements, each separated by a single389 comma (",") and optional whitespace (OWS, <xref target="basic.rules"/>).390 </t>391 <figure><preamble>392 Thus,393 </preamble><artwork type="example">394 1#element => element *( OWS "," OWS element )395 </artwork></figure>396 <figure><preamble>397 and:398 </preamble><artwork type="example">399 #element => [ 1#element ]400 </artwork></figure>401 <figure><preamble>402 and for n >= 1 and m > 1:403 </preamble><artwork type="example">404 <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )405 </artwork></figure>406 <t>407 For compatibility with legacy list rules, recipients &SHOULD; accept empty408 list elements. In other words, consumers would follow the list productions:409 </t>410 <figure><artwork type="example">411 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]412 413 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )414 </artwork></figure>415 <t>416 Note that empty elements do not contribute to the count of elements present,417 though.418 </t>419 <t>420 For example, given these ABNF productions:421 </t>422 <figure><artwork type="example">423 example-list = 1#example-list-elmt424 example-list-elmt = token ; see <xref target="field.rules"/>425 </artwork></figure>426 <t>427 Then these are valid values for example-list (not including the double428 quotes, which are present for delimitation only):429 </t>430 <figure><artwork type="example">431 "foo,bar"432 "foo ,bar,"433 "foo , ,bar,charlie "434 </artwork></figure>435 <t>436 But these values would be invalid, as at least one non-empty element is437 required:438 </t>439 <figure><artwork type="example">440 ""441 ","442 ", ,"443 </artwork></figure>444 <t>445 <xref target="collected.abnf"/> shows the collected ABNF, with the list rules446 expanded as explained above.447 </t>448 </section>449 450 <section title="Basic Rules" anchor="basic.rules">451 <t anchor="rule.LWS">452 This specification uses three rules to denote the use of linear453 whitespace: OWS (optional whitespace), RWS (required whitespace), and454 BWS ("bad" whitespace).455 </t>456 <t anchor="rule.OWS">457 The OWS rule is used where zero or more linear whitespace octets might458 appear. OWS &SHOULD; either not be produced or be produced as a single459 SP. Multiple OWS octets that occur within field-content &SHOULD; either460 be replaced with a single SP or transformed to all SP octets (each461 octet other than SP replaced with SP) before interpreting the field value462 or forwarding the message downstream.463 </t>464 <t anchor="rule.RWS">465 RWS is used when at least one linear whitespace octet is required to466 separate field tokens. RWS &SHOULD; be produced as a single SP.467 Multiple RWS octets that occur within field-content &SHOULD; either468 be replaced with a single SP or transformed to all SP octets before469 interpreting the field value or forwarding the message downstream.470 </t>471 <t anchor="rule.BWS">472 BWS is used where the grammar allows optional whitespace for historical473 reasons but senders &SHOULD-NOT; produce it in messages. HTTP/1.1474 recipients &MUST; accept such bad optional whitespace and remove it before475 interpreting the field value or forwarding the message downstream.476 </t>477 <t anchor="rule.whitespace">478 <x:anchor-alias value="BWS"/>479 <x:anchor-alias value="OWS"/>480 <x:anchor-alias value="RWS"/>481 <x:anchor-alias value="obs-fold"/>482 </t>483 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="OWS"/><iref primary="true" item="Grammar" subitem="RWS"/><iref primary="true" item="Grammar" subitem="BWS"/>484 <x:ref>OWS</x:ref> = *( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> / obs-fold )485 ; "optional" whitespace486 <x:ref>RWS</x:ref> = 1*( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> / obs-fold )487 ; "required" whitespace488 <x:ref>BWS</x:ref> = <x:ref>OWS</x:ref>489 ; "bad" whitespace490 <x:ref>obs-fold</x:ref> = <x:ref>CRLF</x:ref> ( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> )491 ; obsolete line folding492 ; see <xref target="field.parsing"/>493 </artwork></figure>494 </section>495 355 </section> 496 356 </section> … … 615 475 <x:span anchor="exbody">Hello World! 616 476 </x:span></artwork></figure> 617 </section>618 619 <section title="Message Orientation and Buffering" anchor="message-orientation-and-buffering">620 <t>621 Fundamentally, HTTP is a message-based protocol. Although message bodies can622 be chunked (<xref target="chunked.encoding"/>) and implementations often623 make parts of a message available progressively, this is not required, and624 some widely-used implementations only make a message available when it is625 complete. Furthermore, while most proxies will progressively stream messages,626 some amount of buffering will take place, and some proxies might buffer627 messages to perform transformations, check content or provide other services.628 </t>629 <t>630 Therefore, extensions to and uses of HTTP cannot rely on the availability of631 a partial message, or assume that messages will not be buffered. There are632 strategies that can be used to test for buffering in a given connection, but633 it should be understood that behaviors can differ across connections, and634 between requests and responses.635 </t>636 <t>637 Recipients &MUST; consider every message in a connection in isolation;638 because HTTP is a stateless protocol, it cannot be assumed that two requests639 on the same connection are from the same client or share any other common640 attributes. In particular, intermediaries might mix requests from different641 clients into a single server connection. Note that some existing HTTP642 extensions (e.g., <xref target="RFC4559"/>) violate this requirement, thereby643 potentially causing interoperability and security problems.644 </t>645 477 </section> 646 478 … … 790 622 They are indistinguishable from a man-in-the-middle attack. 791 623 </t> 624 <t> 625 HTTP is defined as a stateless protocol, meaning that each request message 626 can be understood in isolation. Many implementations depend on HTTP's 627 stateless design in order to reuse proxied connections or dynamically 628 load balance requests across multiple servers. Hence, servers &MUST-NOT; 629 assume that two requests on the same connection are from the same user 630 agent unless the connection is secured and specific to that agent. 631 Some non-standard HTTP extensions (e.g., <xref target="RFC4559"/>) have 632 been known to violate this requirement, resulting in security and 633 interoperability problems. 634 </t> 792 635 </section> 793 636 … … 830 673 broadcast or multicast cache entries, organizations that distribute 831 674 subsets of cached data via optical media, and so on. 675 </t> 676 </section> 677 678 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> 679 <t> 680 This specification targets conformance criteria according to the role of 681 a participant in HTTP communication. Hence, HTTP requirements are placed 682 on senders, recipients, clients, servers, user agents, intermediaries, 683 origin servers, proxies, gateways, or caches, depending on what behavior 684 is being constrained by the requirement. 685 </t> 686 <t> 687 An implementation is considered conformant if it complies with all of the 688 requirements associated with the roles it partakes in HTTP. 689 </t> 690 <t> 691 Senders &MUST-NOT; generate protocol elements that do not match the grammar 692 defined by the ABNF rules for those protocol elements. 693 </t> 694 <t> 695 Unless otherwise noted, recipients &MAY; attempt to recover a usable 696 protocol element from an invalid construct. HTTP does not define 697 specific error handling mechanisms except when they have a direct impact 698 on security, since different applications of the protocol require 699 different error handling strategies. For example, a Web browser might 700 wish to transparently recover from a response where the Location header 701 field doesn't parse according to the ABNF, whereas a systems control 702 client might consider any form of error recovery to be dangerous. 832 703 </t> 833 704 </section> … … 1202 1073 after message parsing has delineated the individual fields. 1203 1074 </t> 1075 <t> 1076 An HTTP message can be parsed as a stream for incremental processing or 1077 forwarding downstream. However, recipients cannot rely on incremental 1078 delivery of partial messages, since some implementations will buffer or 1079 delay message forwarding for the sake of network efficiency, security 1080 checks, or payload transformations. 1081 </t> 1204 1082 1205 1083 <section title="Start Line" anchor="start.line"> … … 1335 1213 </section> 1336 1214 </section> 1337 1338 1215 </section> 1339 1216 … … 1412 1289 </t> 1413 1290 </x:note> 1291 1292 <section title="Whitespace" anchor="whitespace"> 1293 <t anchor="rule.LWS"> 1294 This specification uses three rules to denote the use of linear 1295 whitespace: OWS (optional whitespace), RWS (required whitespace), and 1296 BWS ("bad" whitespace). 1297 </t> 1298 <t anchor="rule.OWS"> 1299 The OWS rule is used where zero or more linear whitespace octets might 1300 appear. OWS &SHOULD; either not be produced or be produced as a single 1301 SP. Multiple OWS octets that occur within field-content &SHOULD; either 1302 be replaced with a single SP or transformed to all SP octets (each 1303 octet other than SP replaced with SP) before interpreting the field value 1304 or forwarding the message downstream. 1305 </t> 1306 <t anchor="rule.RWS"> 1307 RWS is used when at least one linear whitespace octet is required to 1308 separate field tokens. RWS &SHOULD; be produced as a single SP. 1309 Multiple RWS octets that occur within field-content &SHOULD; either 1310 be replaced with a single SP or transformed to all SP octets before 1311 interpreting the field value or forwarding the message downstream. 1312 </t> 1313 <t anchor="rule.BWS"> 1314 BWS is used where the grammar allows optional whitespace for historical 1315 reasons but senders &SHOULD-NOT; produce it in messages. HTTP/1.1 1316 recipients &MUST; accept such bad optional whitespace and remove it before 1317 interpreting the field value or forwarding the message downstream. 1318 </t> 1319 <t anchor="rule.whitespace"> 1320 <x:anchor-alias value="BWS"/> 1321 <x:anchor-alias value="OWS"/> 1322 <x:anchor-alias value="RWS"/> 1323 <x:anchor-alias value="obs-fold"/> 1324 </t> 1325 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="OWS"/><iref primary="true" item="Grammar" subitem="RWS"/><iref primary="true" item="Grammar" subitem="BWS"/> 1326 <x:ref>OWS</x:ref> = *( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> / obs-fold ) 1327 ; "optional" whitespace 1328 <x:ref>RWS</x:ref> = 1*( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> / obs-fold ) 1329 ; "required" whitespace 1330 <x:ref>BWS</x:ref> = <x:ref>OWS</x:ref> 1331 ; "bad" whitespace 1332 <x:ref>obs-fold</x:ref> = <x:ref>CRLF</x:ref> ( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> ) 1333 ; obsolete line folding 1334 ; see <xref target="field.parsing"/> 1335 </artwork></figure> 1336 </section> 1414 1337 1415 1338 <section title="Field Parsing" anchor="field.parsing"> … … 1476 1399 </section> 1477 1400 1478 <section title=" Common Field ABNF Rules" anchor="field.rules">1401 <section title="Field value components" anchor="field.components"> 1479 1402 <t anchor="rule.token.separators"> 1480 1403 <x:anchor-alias value="tchar"/> … … 1553 1476 Senders &SHOULD-NOT; escape octets in comments that do not require escaping 1554 1477 (i.e., other than the backslash octet "\" and the parentheses "(" and ")"). 1478 </t> 1479 </section> 1480 1481 <section title="ABNF list extension: #rule" anchor="abnf.extension"> 1482 <t> 1483 A #rule extension to the ABNF rules of <xref target="RFC5234"/> is used to 1484 improve readability in the definitions of some header field values. 1485 </t> 1486 <t> 1487 A construct "#" is defined, similar to "*", for defining comma-delimited 1488 lists of elements. The full form is "<n>#<m>element" indicating 1489 at least <n> and at most <m> elements, each separated by a single 1490 comma (",") and optional whitespace (OWS). 1491 </t> 1492 <figure><preamble> 1493 Thus, 1494 </preamble><artwork type="example"> 1495 1#element => element *( OWS "," OWS element ) 1496 </artwork></figure> 1497 <figure><preamble> 1498 and: 1499 </preamble><artwork type="example"> 1500 #element => [ 1#element ] 1501 </artwork></figure> 1502 <figure><preamble> 1503 and for n >= 1 and m > 1: 1504 </preamble><artwork type="example"> 1505 <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) 1506 </artwork></figure> 1507 <t> 1508 For compatibility with legacy list rules, recipients &SHOULD; accept empty 1509 list elements. In other words, consumers would follow the list productions: 1510 </t> 1511 <figure><artwork type="example"> 1512 #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 1513 1514 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 1515 </artwork></figure> 1516 <t> 1517 Note that empty elements do not contribute to the count of elements present, 1518 though. 1519 </t> 1520 <t> 1521 For example, given these ABNF productions: 1522 </t> 1523 <figure><artwork type="example"> 1524 example-list = 1#example-list-elmt 1525 example-list-elmt = token ; see <xref target="field.components"/> 1526 </artwork></figure> 1527 <t> 1528 Then these are valid values for example-list (not including the double 1529 quotes, which are present for delimitation only): 1530 </t> 1531 <figure><artwork type="example"> 1532 "foo,bar" 1533 "foo ,bar," 1534 "foo , ,bar,charlie " 1535 </artwork></figure> 1536 <t> 1537 But these values would be invalid, as at least one non-empty element is 1538 required: 1539 </t> 1540 <figure><artwork type="example"> 1541 "" 1542 "," 1543 ", ," 1544 </artwork></figure> 1545 <t> 1546 <xref target="collected.abnf"/> shows the collected ABNF, with the list rules 1547 expanded as explained above. 1555 1548 </t> 1556 1549 </section> … … 1811 1804 <section title="Types of Request Target" anchor="request-target-types"> 1812 1805 <t> 1813 The four options for request-target are dependent on the nature of the 1814 request. 1806 The proper format choice of the four options available to request-target 1807 depends on the method being requested and if the request is being made to 1808 a proxy. 1815 1809 </t> 1816 <t anchor="asterix-form"><iref item="asterisk form (of request-target)"/> 1817 The asterisk "*" form of request-target, which &MUST-NOT; be used 1818 with any request method other than OPTIONS, means that the request 1819 applies to the server as a whole (the listening process) rather than 1820 to a specific named resource at that server. For example, 1810 <t anchor="origin-form"><iref item="origin form (of request-target)"/> 1811 The most common form of request-target is that used when making 1812 a request to an origin server ("origin form") to access a resource 1813 identified by an "http" (<xref target="http.uri"/>) or 1814 "https" (<xref target="https.uri"/>) URI. 1815 In this case, the absolute path and query components of the URI 1816 &MUST; be transmitted as the request-target and the authority component 1817 (excluding any userinfo) &MUST; be transmitted in a Host header field. 1818 For example, a client wishing to retrieve a representation of the resource 1819 identified as 1820 </t> 1821 <figure><artwork x:indent-with=" "> 1822 http://www.example.org/where?q=now 1823 </artwork></figure> 1824 <t> 1825 directly from the origin server would open (or reuse) a TCP connection 1826 to port 80 of the host "www.example.org" and send the lines: 1821 1827 </t> 1822 1828 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 1823 OPTIONS * HTTP/1.1 1824 </artwork></figure> 1829 GET /where?q=now HTTP/1.1 1830 Host: www.example.org 1831 </artwork></figure> 1832 <t> 1833 followed by the remainder of the request. Note that the origin form 1834 of request-target always starts with an absolute path. If the target 1835 resource's URI path is empty, then an absolute path of "/" &MUST; be 1836 provided in the request-target. 1837 </t> 1838 <t> 1839 If the request-target is percent-encoded 1840 (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>), the origin server 1841 &MUST; decode the request-target in order to 1842 properly interpret the request. Servers &SHOULD; respond to invalid 1843 request-targets with an appropriate status code. 1844 </t> 1825 1845 <t anchor="absolute-URI-form"><iref item="absolute-URI form (of request-target)"/> 1826 The "absolute-URI" form is &REQUIRED; when the request is being made to a1827 proxy. The proxy is requested to either forward the request or service it1828 from a valid cache, and then return the response. Note that the proxy &MAY;1829 forward the request on to another proxy or directly to the server1830 specified by the absolute-URI. In order to avoid request loops, a1831 proxy that forwards requests to other proxies &MUST; be able to1832 recognize and exclude all of its own server names, including1833 any aliases, local variations, and the numeric IP address. An example1834 Request-Line would be:1846 The "absolute-URI" form of request-target is &REQUIRED; when the request 1847 is being made to a proxy. The proxy is requested to either forward the 1848 request or service it from a valid cache, and then return the response. 1849 Note that the proxy &MAY; forward the request on to another proxy or 1850 directly to the server specified by the absolute-URI. 1851 In order to avoid request loops, a proxy that forwards requests to other 1852 proxies &MUST; be able to recognize and exclude all of its own server 1853 names, including any aliases, local variations, or literal IP addresses. 1854 An example Request-Line would be: 1835 1855 </t> 1836 1856 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> … … 1850 1870 </t> 1851 1871 <t anchor="authority-form"><iref item="authority form (of request-target)"/> 1852 The "authority form" is only used by the CONNECT request method (&CONNECT;). 1853 </t> 1854 <t anchor="origin-form"><iref item="origin form (of request-target)"/> 1855 The most common form of request-target is that used when making 1856 a request to an origin server ("origin form"). 1857 In this case, the absolute path and query components of the URI 1858 &MUST; be transmitted as the request-target, and the authority component 1859 &MUST; be transmitted in a Host header field. For example, a client wishing 1860 to retrieve a representation of the resource, as identified above, 1861 directly from the origin server would open (or reuse) a TCP connection 1862 to port 80 of the host "www.example.org" and send the lines: 1872 The "authority form" of request-target, which &MUST-NOT; be used 1873 with any request method other than CONNECT, is used to establish a 1874 tunnel through one or more proxies (&CONNECT;). For example, 1863 1875 </t> 1864 1876 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 1865 GET /pub/WWW/TheProject.html HTTP/1.1 1866 Host: www.example.org 1867 </artwork></figure> 1868 <t> 1869 followed by the remainder of the Request. Note that the origin form 1870 of request-target always starts with an absolute path; if the target 1871 resource's URI path is empty, then an absolute path of "/" &MUST; be 1872 provided in the request-target. 1873 </t> 1877 CONNECT www.example.com:80 HTTP/1.1 1878 </artwork></figure> 1879 <t anchor="asterix-form"><iref item="asterisk form (of request-target)"/> 1880 The asterisk ("*") form of request-target, which &MUST-NOT; be used 1881 with any request method other than OPTIONS, means that the request 1882 applies to the server as a whole (the listening process) rather than 1883 to a specific named resource at that server. For example, 1884 </t> 1885 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 1886 OPTIONS * HTTP/1.1 1887 </artwork></figure> 1874 1888 <t> 1875 1889 If a proxy receives an OPTIONS request with an absolute-URI form of … … 1894 1908 </figure> 1895 1909 <t> 1896 The request-target is transmitted in the format specified in1897 <xref target="http.uri"/>. If the request-target is percent-encoded1898 (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>), the origin server1899 &MUST; decode the request-target in order to1900 properly interpret the request. Servers &SHOULD; respond to invalid1901 request-targets with an appropriate status code.1902 </t>1903 <t>1904 1910 A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" and "query" 1905 1911 parts of the received request-target when forwarding it to the next inbound … … 1907 1913 "*". 1908 1914 </t> 1909 <x:note>1910 <t>1911 <x:h>Note:</x:h> The "no rewrite" rule above prevents the proxy from1912 changing the meaning of the request when the origin server is improperly1913 using a non-reserved URI character for a reserved purpose. Implementors1914 need to be aware that some pre-HTTP/1.1 proxies have been known to1915 rewrite the request-target.1916 </t>1917 </x:note>1918 1915 </section> 1919 1916 … … 4941 4938 <t> 4942 4939 Empty list elements in list productions have been deprecated. 4943 (<xref target=" notation.abnf"/>)4940 (<xref target="abnf.extension"/>) 4944 4941 </t> 4945 4942 <t> 4946 4943 Rules about implicit linear whitespace between certain grammar productions 4947 have been removed; now it's only allowed when specifically pointed out4948 in the ABNF.4949 (<xref target=" basic.rules"/>)4944 have been removed; now whitespace is only allowed where specifically 4945 defined in the ABNF. 4946 (<xref target="whitespace"/>) 4950 4947 </t> 4951 4948 <t> … … 4965 4962 Non-ASCII content in header fields and reason phrase has been obsoleted and 4966 4963 made opaque (the TEXT rule was removed). 4967 (<xref target="field. rules"/>)4964 (<xref target="field.components"/>) 4968 4965 </t> 4969 4966 <t> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1516 r1518 27 27 <!ENTITY content-negotiation "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 28 <!ENTITY agent-driven-negotiation "<xref target='Part3' x:rel='#agent-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 29 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">30 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">31 <!ENTITY field- rules "<xref target='Part1' x:rel='#field.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">29 <!ENTITY abnf-extension "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 <!ENTITY whitespace "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 <!ENTITY field-components "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 32 <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 33 33 <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 346 346 <x:anchor-alias value="SP"/> 347 347 <t> 348 This specification uses the ABNF syntax defined in ¬ation; (which349 extends the syntax defined in <xref target="RFC5234"/> with a list rule).350 <xref target="collected.abnf"/> shows the collected ABNF, with the list351 rule expanded.348 This specification uses the Augmented Backus-Naur Form (ABNF) notation 349 of <xref target="RFC5234"/> with the list rule extension defined in 350 ¬ation;. <xref target="collected.abnf"/> shows the collected ABNF 351 with the list rule expanded. 352 352 </t> 353 353 <t> … … 372 372 </t> 373 373 <figure><artwork type="abnf2616"> 374 <x:ref>BWS</x:ref> = <BWS, defined in & basic-rules;>375 <x:ref>OWS</x:ref> = <OWS, defined in & basic-rules;>376 <x:ref>RWS</x:ref> = <RWS, defined in & basic-rules;>377 <x:ref>obs-text</x:ref> = <obs-text, defined in & basic-rules;>378 <x:ref>quoted-string</x:ref> = <quoted-string, defined in &field- rules;>379 <x:ref>token</x:ref> = <token, defined in &field- rules;>374 <x:ref>BWS</x:ref> = <BWS, defined in &whitespace;> 375 <x:ref>OWS</x:ref> = <OWS, defined in &whitespace;> 376 <x:ref>RWS</x:ref> = <RWS, defined in &whitespace;> 377 <x:ref>obs-text</x:ref> = <obs-text, defined in &field-components;> 378 <x:ref>quoted-string</x:ref> = <quoted-string, defined in &field-components;> 379 <x:ref>token</x:ref> = <token, defined in &field-components;> 380 380 </artwork></figure> 381 381 </section> … … 392 392 <figure><!--Part1--><artwork type="abnf2616"> 393 393 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in &uri;> 394 <x:ref>comment</x:ref> = <comment, defined in &field- rules;>394 <x:ref>comment</x:ref> = <comment, defined in &field-components;> 395 395 <x:ref>partial-URI</x:ref> = <partial-URI, defined in &uri;> 396 396 <x:ref>product</x:ref> = <product, defined in &product-tokens;> … … 525 525 <t> 526 526 New header field values typically have their syntax defined using ABNF 527 (<xref target="RFC5234"/>), using the extension s defined in ¬ation-abnf;527 (<xref target="RFC5234"/>), using the extension defined in &abnf-extension; 528 528 as necessary, and are usually constrained to the range of ASCII characters. 529 529 Header fields needing a greater range of characters can use an encoding … … 534 534 they need to be treated with care if they are allowed in the field-value's 535 535 payload. Typically, components that might contain a comma are protected with 536 double-quotes using the quoted-string ABNF production (&field- rules;).536 double-quotes using the quoted-string ABNF production (&field-components;). 537 537 </t> 538 538 <t> -
draft-ietf-httpbis/latest/p3-payload.xml
r1514 r1518 18 18 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 19 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">20 <!ENTITY abnf-extension "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 21 <!ENTITY acks "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 22 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">23 <!ENTITY field- rules "<xref target='Part1' x:rel='#field.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">22 <!ENTITY whitespace "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 23 <!ENTITY field-components "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 24 24 <!ENTITY caching-neg-resp "<xref target='Part6' x:rel='#caching.negotiated.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 25 <!ENTITY header-transfer-encoding "<xref target='Part1' x:rel='#header.transfer-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 312 312 <x:anchor-alias value="VCHAR"/> 313 313 <t> 314 This specification uses the ABNF syntax defined in ¬ation; (which315 extends the syntax defined in <xref target="RFC5234"/> with a list rule).316 <xref target="collected.abnf"/> shows the collected ABNF, with the list317 rule expanded.314 This specification uses the Augmented Backus-Naur Form (ABNF) notation 315 of <xref target="RFC5234"/> with the list rule extension defined in 316 ¬ation;. <xref target="collected.abnf"/> shows the collected ABNF 317 with the list rule expanded. 318 318 </t> 319 319 <t> … … 335 335 </t> 336 336 <figure><artwork type="abnf2616"> 337 <x:ref>OWS</x:ref> = <OWS, defined in & basic-rules;>338 <x:ref>token</x:ref> = <token, defined in &field- rules;>339 <x:ref>word</x:ref> = <word, defined in &field- rules;>337 <x:ref>OWS</x:ref> = <OWS, defined in &whitespace;> 338 <x:ref>token</x:ref> = <token, defined in &field-components;> 339 <x:ref>word</x:ref> = <word, defined in &field-components;> 340 340 </artwork></figure> 341 341 </section> -
draft-ietf-httpbis/latest/p4-conditional.xml
r1514 r1518 17 17 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 18 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">19 <!ENTITY abnf-extension "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 20 <!ENTITY acks "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">22 <!ENTITY field- rules "<xref target='Part1' x:rel='#field.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">21 <!ENTITY whitespace "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 22 <!ENTITY field-components "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 23 23 <!ENTITY header-date "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 24 24 <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 304 304 <x:anchor-alias value="HTTP-date"/> 305 305 <t> 306 This specification uses the ABNF syntax defined in ¬ation; (which307 extends the syntax defined in <xref target="RFC5234"/> with a list rule).308 <xref target="collected.abnf"/> shows the collected ABNF, with the list309 rule expanded.306 This specification uses the Augmented Backus-Naur Form (ABNF) notation 307 of <xref target="RFC5234"/> with the list rule extension defined in 308 ¬ation;. <xref target="collected.abnf"/> shows the collected ABNF 309 with the list rule expanded. 310 310 </t> 311 311 <t> … … 323 323 </t> 324 324 <figure><artwork type="abnf2616"> 325 <x:ref>OWS</x:ref> = <OWS, defined in & basic-rules;>326 <x:ref>obs-text</x:ref> = <obs-text, defined in &field- rules;>325 <x:ref>OWS</x:ref> = <OWS, defined in &whitespace;> 326 <x:ref>obs-text</x:ref> = <obs-text, defined in &field-components;> 327 327 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &http-date;> 328 328 </artwork></figure> -
draft-ietf-httpbis/latest/p5-range.xml
r1500 r1518 17 17 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 18 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">19 <!ENTITY abnf-extension "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 20 <!ENTITY acks "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">22 <!ENTITY field- rules "<xref target='Part1' x:rel='#field.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">21 <!ENTITY whitespace "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 22 <!ENTITY field-components "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 23 23 <!ENTITY http-date "<xref target='Part2' x:rel='#http.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 24 24 <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 290 290 <x:anchor-alias value="VCHAR"/> 291 291 <t> 292 This specification uses the ABNF syntax defined in ¬ation; (which293 extends the syntax defined in <xref target="RFC5234"/> with a list rule).294 <xref target="collected.abnf"/> shows the collected ABNF, with the list295 rule expanded.292 This specification uses the Augmented Backus-Naur Form (ABNF) notation 293 of <xref target="RFC5234"/> with the list rule extension defined in 294 ¬ation;. <xref target="collected.abnf"/> shows the collected ABNF 295 with the list rule expanded. 296 296 </t> 297 297 <t> … … 320 320 </t> 321 321 <figure><artwork type="abnf2616"> 322 <x:ref>OWS</x:ref> = <OWS, defined in & basic-rules;>323 <x:ref>token</x:ref> = <token, defined in &field- rules;>322 <x:ref>OWS</x:ref> = <OWS, defined in &whitespace;> 323 <x:ref>token</x:ref> = <token, defined in &field-components;> 324 324 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &http-date;> 325 325 </artwork></figure> -
draft-ietf-httpbis/latest/p6-cache.xml
r1514 r1518 15 15 <!ENTITY ID-MONTH "January"> 16 16 <!ENTITY ID-YEAR "2012"> 17 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">17 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 18 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 19 <!ENTITY acks "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">21 <!ENTITY field- rules "<xref target='Part1' x:rel='#field.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">20 <!ENTITY whitespace "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 <!ENTITY field-components "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 22 22 <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 23 23 <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 435 435 <x:anchor-alias value="VCHAR"/> 436 436 <t> 437 This specification uses the A BNF syntax defined in ¬ation; (which438 extends the syntax defined in <xref target="RFC5234"/> with a list rule).439 <xref target="collected.abnf"/> shows the collected ABNF, with the list440 rule expanded.437 This specification uses the Augmented Backus-Naur Form (ABNF) notation 438 of <xref target="RFC5234"/> with the list rule extension defined in 439 ¬ation;. <xref target="collected.abnf"/> shows the collected ABNF 440 with the list rule expanded. 441 441 </t> 442 442 <t> … … 456 456 </t> 457 457 <figure><artwork type="abnf2616"> 458 <x:ref>OWS</x:ref> = <OWS, defined in & basic-rules;>459 <x:ref>quoted-string</x:ref> = <quoted-string, defined in &field- rules;>460 <x:ref>token</x:ref> = <token, defined in &field- rules;>458 <x:ref>OWS</x:ref> = <OWS, defined in &whitespace;> 459 <x:ref>quoted-string</x:ref> = <quoted-string, defined in &field-components;> 460 <x:ref>token</x:ref> = <token, defined in &field-components;> 461 461 </artwork></figure> 462 462 </section> -
draft-ietf-httpbis/latest/p7-auth.xml
r1500 r1518 18 18 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 19 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">20 <!ENTITY abnf-extension "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 21 <!ENTITY acks "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 22 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">23 <!ENTITY field- rules "<xref target='Part1' x:rel='#field.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">22 <!ENTITY whitespace "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 23 <!ENTITY field-components "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 24 24 <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 <!ENTITY msg-orient-and-buffering "<xref target='Part1' x:rel='# message-orientation-and-buffering' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">25 <!ENTITY msg-orient-and-buffering "<xref target='Part1' x:rel='#intermediaries' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 26 <!ENTITY end-to-end.and-hop-by-hop "<xref target='Part1' x:rel='#end-to-end.and.hop-by-hop.header-fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 27 27 <!ENTITY shared-and-non-shared-caches "<xref target='Part6' x:rel='#shared.and.non-shared.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 275 275 <x:anchor-alias value="SP"/> 276 276 <t> 277 This specification uses the ABNF syntax defined in ¬ation; (which278 extends the syntax defined in <xref target="RFC5234"/> with a list rule).279 <xref target="collected.abnf"/> shows the collected ABNF, with the list280 rule expanded.277 This specification uses the Augmented Backus-Naur Form (ABNF) notation 278 of <xref target="RFC5234"/> with the list rule extension defined in 279 ¬ation;. <xref target="collected.abnf"/> shows the collected ABNF 280 with the list rule expanded. 281 281 </t> 282 282 <t> … … 299 299 </t> 300 300 <figure><artwork type="abnf2616"> 301 <x:ref>BWS</x:ref> = <BWS, defined in & basic-rules;>302 <x:ref>OWS</x:ref> = <OWS, defined in & basic-rules;>303 <x:ref>quoted-string</x:ref> = <quoted-string, defined in &field- rules;>304 <x:ref>token</x:ref> = <token, defined in &field- rules;>301 <x:ref>BWS</x:ref> = <BWS, defined in &whitespace;> 302 <x:ref>OWS</x:ref> = <OWS, defined in &whitespace;> 303 <x:ref>quoted-string</x:ref> = <quoted-string, defined in &field-components;> 304 <x:ref>token</x:ref> = <token, defined in &field-components;> 305 305 </artwork></figure> 306 306 </section> … … 492 492 <x:lt> 493 493 <t> 494 Authentication schemes need to be compatible with the inherent 495 constraints of HTTP; for instance, that messages need to keep their 496 semantics when inspected in isolation, thus an authentication scheme 497 can not bind information to the TCP session over which the message 498 was received (see &msg-orient-and-buffering;). 494 HTTP authentication is presumed to be stateless: all of the information 495 necessary to authenticate a request &MUST; be provided in the request, 496 rather than be dependent on the server remembering prior requests. 497 Authentication based on, or bound to, the underlying connection is 498 outside the scope of this specification and inherently flawed unless 499 steps are taken to ensure that the connection cannot be used by any 500 party other than the authenticated user 501 (see &msg-orient-and-buffering;). 499 502 </t> 500 503 </x:lt>
Note: See TracChangeset
for help on using the changeset viewer.