Changeset 391 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 15/11/08 00:44:55 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r390 r391 230 230 The Hypertext Transfer Protocol (HTTP) is an application-level 231 231 request/response protocol that uses extensible semantics and MIME-like 232 message payloads for flexible interaction with network-based hyper media232 message payloads for flexible interaction with network-based hypertext 233 233 information systems. HTTP relies upon the Uniform Resource Identifier (URI) 234 standard <xref target="RFC3986"/> to indicate resource targets for235 interaction and to identify otherresources.234 standard <xref target="RFC3986"/> to indicate resource targets and 235 relationships between resources. 236 236 Messages are passed in a format similar to that used by Internet mail 237 237 <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions 238 238 (MIME) <xref target="RFC2045"/> (see &diff2045entity; for the differences 239 239 between HTTP and MIME messages). 240 </t> 241 <t> 242 HTTP is a generic interface protocol for informations systems. It is 243 designed to hide the details of how a service is implemented by presenting 244 a uniform interface to clients that is independent of the types of 245 resources provided. Likewise, servers do not need to be aware of each 246 client's purpose: an HTTP request can be considered in isolation rather 247 than being associated with a specific type of client or a predetermined 248 sequence of application steps. The result is a protocol that can be used 249 effectively in many different contexts and for which implementations can 250 evolve independently over time. 240 251 </t> 241 252 <t> … … 251 262 </t> 252 263 <t> 264 One consequence of HTTP flexibility is that we cannot define the protocol 265 in terms of how to implement it behind the interface. Instead, we are 266 limited to restricting the syntax of communication, defining the intent 267 of received communication, and the expected behavior of recipients. If 268 the communication is considered in isolation, then successful actions 269 should be reflected in the observable interface provided by servers. 270 However, since many clients are potentially acting in parallel and 271 perhaps at cross-purposes, it would be meaningless to require that such 272 behavior be observable. 273 </t> 274 <t> 253 275 This document is Part 1 of the seven-part specification of HTTP, 254 276 defining the protocol referred to as "HTTP/1.1" and obsoleting 255 277 <xref target="RFC2616"/>. 256 Part 1 defines how clients determine when to use HTTP, the URI schemes257 specific to HTTP-based resources, overall network operation with258 transport protocol connection management, and HTTP message framing.278 Part 1 defines the URI schemes specific to HTTP-based resources, overall 279 network operation, transport protocol connection management, and HTTP 280 message framing and forwarding requirements. 259 281 Our goal is to define all of the mechanisms necessary for HTTP message 260 282 handling that are independent of message semantics, thereby defining the 261 complete set of requirements for a n HTTP message relay or generic262 message parser.283 complete set of requirements for a message parser and transparent 284 message-forwarding intermediaries. 263 285 </t> 264 286 … … 503 525 504 526 </section> 527 </section> 528 529 <section title="HTTP architecture" anchor="architecture"> 530 <t> 531 HTTP was created with a specific architecture in mind, the World Wide Web, 532 and has evolved over time to support the scalability needs of a worldwide 533 hypertext system. Much of that architecture is reflected in the terminology 534 and syntax productions used to define HTTP. 535 </t> 536 537 <section title="Uniform Resource Identifiers" anchor="uri"> 538 <t> 539 Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used 540 throughout HTTP as the means for identifying resources. URI references 541 are used to target requests, redirect responses, and define relationships. 542 HTTP does not limit what a resource may be; it merely defines an interface 543 that can be used to interact with a resource via HTTP. More information on 544 the scope of URIs and resources can be found in <xref target="RFC3986"/>. 545 </t> 546 <x:anchor-alias value="URI"/> 547 <x:anchor-alias value="URI-reference"/> 548 <x:anchor-alias value="absolute-URI"/> 549 <x:anchor-alias value="relative-part"/> 550 <x:anchor-alias value="authority"/> 551 <x:anchor-alias value="fragment"/> 552 <x:anchor-alias value="path-abempty"/> 553 <x:anchor-alias value="path-absolute"/> 554 <x:anchor-alias value="port"/> 555 <x:anchor-alias value="query"/> 556 <x:anchor-alias value="uri-host"/> 557 <x:anchor-alias value="partial-URI"/> 558 <t> 559 This specification adopts the definitions of "URI-reference", 560 "absolute-URI", "relative-part", "fragment", "port", "host", 561 "path-abempty", "path-absolute", "query", and "authority" from 562 <xref target="RFC3986"/>. In addition, we define a partial-URI rule for 563 protocol elements that allow a relative URI without a fragment. 564 </t> 565 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="URI-reference"/><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="uri-host"/> 566 <x:ref>URI</x:ref> = <URI, defined in <xref target="RFC3986" x:fmt="," x:sec="3"/>> 567 <x:ref>URI-reference</x:ref> = <URI-reference, defined in <xref target="RFC3986" x:fmt="," x:sec="4.1"/>> 568 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>> 569 <x:ref>relative-part</x:ref> = <relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/>> 570 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>> 571 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>> 572 <x:ref>path-abempty</x:ref> = <path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>> 573 <x:ref>path-absolute</x:ref> = <path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>> 574 <x:ref>port</x:ref> = <port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>> 575 <x:ref>query</x:ref> = <query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>> 576 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>> 577 578 <x:ref>partial-URI</x:ref> = relative-part [ "?" query ] 579 </artwork></figure> 580 <t> 581 Each protocol element in HTTP that allows a URI reference will indicate in 582 its ABNF production whether the element allows only a URI in absolute form 583 (absolute-URI), any relative reference (relative-ref), or some other subset 584 of the URI-reference grammar. Unless otherwise indicated, URI references 585 are parsed relative to the request target (the default base URI for both 586 the request and its corresponding response). 587 </t> 588 589 <section title="http URI scheme" anchor="http.uri"> 590 <x:anchor-alias value="http-URI"/> 591 <iref item="http URI scheme" primary="true"/> 592 <iref item="URI scheme" subitem="http" primary="true"/> 593 <t> 594 The "http" scheme is used to locate network resources via the HTTP 595 protocol. This section defines the syntax and semantics for identifiers 596 using the http or https URI schemes. 597 </t> 598 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URI"/> 599 <x:ref>http-URI</x:ref> = "http:" "//" <x:ref>authority</x:ref> <x:ref>path-abempty</x:ref> [ "?" <x:ref>query</x:ref> ] 600 </artwork></figure> 601 <t> 602 If the port is empty or not given, port 80 is assumed. The semantics 603 are that the identified resource is located at the server listening 604 for TCP connections on that port of that host, and the request-target 605 for the resource is path-absolute (<xref target="request-target"/>). The use of IP addresses 606 in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If 607 the path-absolute is not present in the URL, it &MUST; be given as "/" when 608 used as a request-target for a resource (<xref target="request-target"/>). If a proxy 609 receives a host name which is not a fully qualified domain name, it 610 &MAY; add its domain to the host name it received. If a proxy receives 611 a fully qualified domain name, the proxy &MUST-NOT; change the host 612 name. 613 </t> 614 <t><list><t> 615 <iref item="https URI scheme"/> 616 <iref item="URI scheme" subitem="https"/> 617 <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>. 618 </t></list></t> 619 </section> 620 621 <section title="URI Comparison" anchor="uri.comparison"> 622 <t> 623 When comparing two URIs to decide if they match or not, a client 624 &SHOULD; use a case-sensitive octet-by-octet comparison of the entire 625 URIs, with these exceptions: 626 <list style="symbols"> 627 <t>A port that is empty or not given is equivalent to the default 628 port for that URI-reference;</t> 629 <t>Comparisons of host names &MUST; be case-insensitive;</t> 630 <t>Comparisons of scheme names &MUST; be case-insensitive;</t> 631 <t>An empty path-absolute is equivalent to an path-absolute of "/".</t> 632 </list> 633 </t> 634 <t> 635 Characters other than those in the "reserved" set (see 636 <xref target="RFC3986" x:fmt="," x:sec="2.2"/>) are equivalent to their 637 ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding. 638 </t> 639 <t> 640 For example, the following three URIs are equivalent: 641 </t> 642 <figure><artwork type="example"> 643 http://example.com:80/~smith/home.html 644 http://EXAMPLE.com/%7Esmith/home.html 645 http://EXAMPLE.com:/%7esmith/home.html 646 </artwork></figure> 647 </section> 648 649 <section title="Scheme aliases considered harmful" anchor="scheme.aliases"> 650 <t> 651 </t> 652 </section> 653 </section> 505 654 506 655 <section title="Overall Operation" anchor="intro.overall.operation"> … … 513 662 including the message's protocol version and a success or error code, 514 663 followed by a MIME-like message containing server information, entity 515 metainformation, and possible entity-body content. The relationship 516 between HTTP and MIME is described in &diff2045entity;. 664 metainformation, and possible entity-body content. 517 665 </t> 518 666 <t> … … 612 760 </t> 613 761 </section> 614 </section> 615 762 763 <section title="Use of HTTP for proxy communication" anchor="http.proxy"> 764 <t> 765 Configured to use HTTP to proxy HTTP or other protocols. 766 </t> 767 </section> 768 <section title="Interception of HTTP for access control" anchor="http.intercept"> 769 <t> 770 Interception of HTTP traffic for initiating access control. 771 </t> 772 </section> 773 <section title="Use of HTTP by other protocols" anchor="http.others"> 774 <t> 775 Profiles of HTTP defined by other protocol. 776 Extensions of HTTP like WebDAV. 777 </t> 778 </section> 779 <section title="Use of HTTP by media type specification" anchor="http.media"> 780 <t> 781 Instructions on composing HTTP requests via hypertext formats. 782 </t> 783 </section> 784 </section> 616 785 617 786 <section title="Protocol Parameters" anchor="protocol.parameters"> … … 688 857 </list> 689 858 </t> 690 </section>691 692 <section title="Uniform Resource Identifiers" anchor="uri">693 <t>694 Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used in HTTP695 to indicate the target of a request and to identify additional resources related696 to that resource, the request, or the response. Each protocol element in HTTP697 that allows a URI reference will indicate in its ABNF whether the element allows698 only a URI in absolute form, any relative reference, or some limited subset of699 the URI-reference grammar. Unless otherwise indicated, relative URI references700 are to be parsed relative to the URI corresponding to the request target701 (the base URI).702 </t>703 <x:anchor-alias value="URI-reference"/>704 <x:anchor-alias value="absolute-URI"/>705 <x:anchor-alias value="authority"/>706 <x:anchor-alias value="fragment"/>707 <x:anchor-alias value="path-abempty"/>708 <x:anchor-alias value="path-absolute"/>709 <x:anchor-alias value="port"/>710 <x:anchor-alias value="query"/>711 <x:anchor-alias value="relativeURI"/>712 <x:anchor-alias value="relative-part"/>713 <x:anchor-alias value="uri-host"/>714 <t>715 This specification adopts the definitions of "URI-reference", "absolute-URI", "fragment", "port",716 "host", "path-abempty", "path-absolute", "query", and "authority" from <xref target="RFC3986"/>:717 </t>718 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="URI-reference"/><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="uri-host"/><iref primary="true" item="Grammar" subitem="relativeURI"/><iref primary="true" item="Grammar" subitem="relative-part"/>719 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>>720 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>>721 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>>722 <x:ref>path-abempty</x:ref> = <path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>723 <x:ref>path-absolute</x:ref> = <path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>724 <x:ref>port</x:ref> = <port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>>725 <x:ref>query</x:ref> = <query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>>726 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>>727 728 <x:ref>relative-part</x:ref> = <relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/>>729 <x:ref>relativeURI</x:ref> = <x:ref>relative-part</x:ref> [ "?" <x:ref>query</x:ref> ]730 </artwork></figure>731 <t>732 HTTP does not place an a priori limit on the length of733 a URI. Servers &MUST; be able to handle the URI of any resource they734 serve, and &SHOULD; be able to handle URIs of unbounded length if they735 provide GET-based forms that could generate such URIs. A server736 &SHOULD; return 414 (Request-URI Too Long) status if a URI is longer737 than the server can handle (see &status-414;).738 </t>739 <t>740 <list>741 <t>742 <x:h>Note:</x:h> Servers ought to be cautious about depending on URI lengths743 above 255 bytes, because some older client or proxy744 implementations might not properly support these lengths.745 </t>746 </list>747 </t>748 749 <section title="http URI scheme" anchor="http.uri">750 <x:anchor-alias value="http-URI"/>751 <iref item="http URI scheme" primary="true"/>752 <iref item="URI scheme" subitem="http" primary="true"/>753 <t>754 The "http" scheme is used to locate network resources via the HTTP755 protocol. This section defines the syntax and semantics for identifiers756 using the http or https URI schemes.757 </t>758 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URI"/>759 <x:ref>http-URI</x:ref> = "http:" "//" <x:ref>authority</x:ref> <x:ref>path-abempty</x:ref> [ "?" <x:ref>query</x:ref> ]760 </artwork></figure>761 <t>762 If the port is empty or not given, port 80 is assumed. The semantics763 are that the identified resource is located at the server listening764 for TCP connections on that port of that host, and the Request-URI765 for the resource is path-absolute (<xref target="request-uri"/>). The use of IP addresses766 in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If767 the path-absolute is not present in the URL, it &MUST; be given as "/" when768 used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy769 receives a host name which is not a fully qualified domain name, it770 &MAY; add its domain to the host name it received. If a proxy receives771 a fully qualified domain name, the proxy &MUST-NOT; change the host772 name.773 </t>774 <t><list><t>775 <iref item="https URI scheme"/>776 <iref item="URI scheme" subitem="https"/>777 <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>.778 </t></list></t>779 </section>780 781 <section title="URI Comparison" anchor="uri.comparison">782 <t>783 When comparing two URIs to decide if they match or not, a client784 &SHOULD; use a case-sensitive octet-by-octet comparison of the entire785 URIs, with these exceptions:786 <list style="symbols">787 <t>A port that is empty or not given is equivalent to the default788 port for that URI-reference;</t>789 <t>Comparisons of host names &MUST; be case-insensitive;</t>790 <t>Comparisons of scheme names &MUST; be case-insensitive;</t>791 <t>An empty path-absolute is equivalent to an path-absolute of "/".</t>792 </list>793 </t>794 <t>795 Characters other than those in the "reserved" set (see796 <xref target="RFC3986" x:fmt="," x:sec="2.2"/>) are equivalent to their797 ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding.798 </t>799 <t>800 For example, the following three URIs are equivalent:801 </t>802 <figure><artwork type="example">803 http://example.com:80/~smith/home.html804 http://EXAMPLE.com/%7Esmith/home.html805 http://EXAMPLE.com:/%7esmith/home.html806 </artwork></figure>807 </section>808 859 </section> 809 860 … … 1415 1466 <t> 1416 1467 The Request-Line begins with a method token, followed by the 1417 Request-URIand the protocol version, and ending with CRLF. The1468 request-target and the protocol version, and ending with CRLF. The 1418 1469 elements are separated by SP characters. No CR or LF is allowed 1419 1470 except in the final CRLF sequence. 1420 1471 </t> 1421 1472 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-Line"/> 1422 <x:ref>Request-Line</x:ref> = <x:ref>Method</x:ref> <x:ref>SP</x:ref> <x:ref> Request-URI</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-Version</x:ref> <x:ref>CRLF</x:ref>1473 <x:ref>Request-Line</x:ref> = <x:ref>Method</x:ref> <x:ref>SP</x:ref> <x:ref>request-target</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-Version</x:ref> <x:ref>CRLF</x:ref> 1423 1474 </artwork></figure> 1424 1475 … … 1427 1478 <t> 1428 1479 The Method token indicates the method to be performed on the 1429 resource identified by the Request-URI. The method is case-sensitive.1480 resource identified by the request-target. The method is case-sensitive. 1430 1481 </t> 1431 1482 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/> … … 1434 1485 </section> 1435 1486 1436 <section title=" Request-URI" anchor="request-uri">1437 <x:anchor-alias value=" Request-URI"/>1438 <t> 1439 The Request-URIis a Uniform Resource Identifier (<xref target="uri"/>) and1487 <section title="request-target" anchor="request-target"> 1488 <x:anchor-alias value="request-target"/> 1489 <t> 1490 The request-target is a Uniform Resource Identifier (<xref target="uri"/>) and 1440 1491 identifies the resource upon which to apply the request. 1441 1492 </t> 1442 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem=" Request-URI"/>1443 <x:ref> Request-URI</x:ref> = "*"1493 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-target"/> 1494 <x:ref>request-target</x:ref> = "*" 1444 1495 / <x:ref>absolute-URI</x:ref> 1445 1496 / ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] ) … … 1447 1498 </artwork></figure> 1448 1499 <t> 1449 The four options for Request-URIare dependent on the nature of the1500 The four options for request-target are dependent on the nature of the 1450 1501 request. The asterisk "*" means that the request does not apply to a 1451 1502 particular resource, but to the server itself, and is only allowed … … 1479 1530 </t> 1480 1531 <t> 1481 The most common form of Request-URIis that used to identify a1532 The most common form of request-target is that used to identify a 1482 1533 resource on an origin server or gateway. In this case the absolute 1483 1534 path of the URI &MUST; be transmitted (see <xref target="http.uri"/>, path-absolute) as 1484 the Request-URI, and the network location of the URI (authority) &MUST;1535 the request-target, and the network location of the URI (authority) &MUST; 1485 1536 be transmitted in a Host header field. For example, a client wishing 1486 1537 to retrieve the resource above directly from the origin server would … … 1498 1549 </t> 1499 1550 <t> 1500 The Request-URIis transmitted in the format specified in1501 <xref target="http.uri"/>. If the Request-URIis encoded using the1551 The request-target is transmitted in the format specified in 1552 <xref target="http.uri"/>. If the request-target is encoded using the 1502 1553 "% <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding 1503 1554 (<xref target="RFC3986" x:fmt="," x:sec="2.4"/>), the origin server 1504 &MUST; decode the Request-URIin order to1555 &MUST; decode the request-target in order to 1505 1556 properly interpret the request. Servers &SHOULD; respond to invalid 1506 Request-URIs with an appropriate status code.1557 request-targets with an appropriate status code. 1507 1558 </t> 1508 1559 <t> 1509 1560 A transparent proxy &MUST-NOT; rewrite the "path-absolute" part of the 1510 received Request-URIwhen forwarding it to the next inbound server,1561 received request-target when forwarding it to the next inbound server, 1511 1562 except as noted above to replace a null path-absolute with "/". 1512 1563 </t> … … 1517 1568 a non-reserved URI character for a reserved purpose. Implementors 1518 1569 should be aware that some pre-HTTP/1.1 proxies have been known to 1519 rewrite the Request-URI.1570 rewrite the request-target. 1520 1571 </t></list> 1521 1572 </t> 1573 <t> 1574 HTTP does not place a pre-defined limit on the length of a request-target. 1575 A server &MUST; be prepared to receive URIs of unbounded length and 1576 respond with the 414 (URI too long) status if the received 1577 request-target would be longer than the server wishes to handle 1578 (see &status-414;). 1579 </t> 1580 <t> 1581 Various ad-hoc limitations on request-target length are found in practice. 1582 It is &RECOMMENDED; that all HTTP senders and recipients support 1583 request-target lengths of 8000 or more OCTETs. 1584 </t> 1522 1585 </section> 1523 1586 </section> … … 1526 1589 <t> 1527 1590 The exact resource identified by an Internet request is determined by 1528 examining both the Request-URIand the Host header field.1591 examining both the request-target and the Host header field. 1529 1592 </t> 1530 1593 <t> … … 1541 1604 resource on an HTTP/1.1 request: 1542 1605 <list style="numbers"> 1543 <t>If Request-URIis an absolute-URI, the host is part of the1544 Request-URI. Any Host header field value in the request &MUST; be1606 <t>If request-target is an absolute-URI, the host is part of the 1607 request-target. Any Host header field value in the request &MUST; be 1545 1608 ignored.</t> 1546 <t>If the Request-URIis not an absolute-URI, and the request includes1609 <t>If the request-target is not an absolute-URI, and the request includes 1547 1610 a Host header field, the host is determined by the Host header 1548 1611 field value.</t> … … 2238 2301 The request-header field "Host" specifies the Internet host and port 2239 2302 number of the resource being requested, as obtained from the original 2240 URI given by the user or referring resource (generally an HTTP URL,2303 URI given by the user or referring resource (generally an http URI, 2241 2304 as described in <xref target="http.uri"/>). The Host field value &MUST; represent 2242 2305 the naming authority of the origin server or gateway given by the … … 2875 2938 other operating systems use ".." as a path component to indicate a 2876 2939 directory level above the current one. On such a system, an HTTP 2877 server &MUST; disallow any such construct in the Request-URIif it2940 server &MUST; disallow any such construct in the request-target if it 2878 2941 would otherwise allow access to a resource outside those intended to 2879 2942 be accessible via the HTTP server. Similarly, files intended for … … 3909 3972 The requirements that clients and servers support the Host request-header, 3910 3973 report an error if the Host request-header (<xref target="header.host"/>) is 3911 missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request- uri"/>)3974 missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>) 3912 3975 are among the most important changes defined by this 3913 3976 specification. … … 4037 4100 Update use of abs_path production from RFC1808 to the path-absolute + query 4038 4101 components of RFC3986. 4039 (<xref target="request- uri"/>)4102 (<xref target="request-target"/>) 4040 4103 </t> 4041 4104 <t> … … 4598 4661 </list> 4599 4662 </t> 4663 <t> 4664 Other changes: 4665 <list style="symbols"> 4666 <t> 4667 Rewrite introduction; add mostly new Architecture Section. 4668 </t> 4669 </list> 4670 </t> 4600 4671 </section> 4601 4672
Note: See TracChangeset
for help on using the changeset viewer.