Changeset 340 for draft-ietf-httpbis/latest-roy
- Timestamp:
- 11/11/08 01:00:46 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest-roy/p1-messaging.xml
r339 r340 306 306 </section> 307 307 308 <section title="Syntax Notation" anchor=" syntax.notation">308 <section title="Syntax Notation" anchor="notation"> 309 309 <t> 310 310 This specification uses the Augmented Backus-Naur Form (ABNF) notation … … 314 314 and SP (space). 315 315 </t> 316 </section> 317 </section> 318 319 <section title="When to use HTTP" anchor="when"> 320 321 <section title="Overall Operation" anchor="intro.overall.operation"> 322 <t> 323 HTTP is a request/response protocol. A client sends a 324 request to the server in the form of a request method, URI, and 325 protocol version, followed by a MIME-like message containing request 326 modifiers, client information, and possible body content over a 327 connection with a server. The server responds with a status line, 328 including the message's protocol version and a success or error code, 329 followed by a MIME-like message containing server information, entity 330 metainformation, and possible entity-body content. The relationship 331 between HTTP and MIME is described in &diff2045entity;. 332 </t> 333 <t> 334 Most HTTP communication is initiated by a user agent and consists of 335 a request to be applied to a resource on some origin server. In the 336 simplest case, this may be accomplished via a single connection (v) 337 between the user agent (UA) and the origin server (O). 338 </t> 339 <figure><artwork type="drawing"> 340 request chain ------------------------> 341 UA -------------------v------------------- O 342 <----------------------- response chain 343 </artwork></figure> 344 <t> 345 A more complicated situation occurs when one or more intermediaries 346 are present in the request/response chain. There are three common 347 forms of intermediary: proxy, gateway, and tunnel. A proxy is a 348 forwarding agent, receiving requests for a URI in its absolute form, 349 rewriting all or part of the message, and forwarding the reformatted 350 request toward the server identified by the URI. A gateway is a 351 receiving agent, acting as a layer above some other server(s) and, if 352 necessary, translating the requests to the underlying server's 353 protocol. A tunnel acts as a relay point between two connections 354 without changing the messages; tunnels are used when the 355 communication needs to pass through an intermediary (such as a 356 firewall) even when the intermediary cannot understand the contents 357 of the messages. 358 </t> 359 <figure><artwork type="drawing"> 360 request chain --------------------------------------> 361 UA -----v----- A -----v----- B -----v----- C -----v----- O 362 <------------------------------------- response chain 363 </artwork></figure> 364 <t> 365 The figure above shows three intermediaries (A, B, and C) between the 366 user agent and origin server. A request or response message that 367 travels the whole chain will pass through four separate connections. 368 This distinction is important because some HTTP communication options 369 may apply only to the connection with the nearest, non-tunnel 370 neighbor, only to the end-points of the chain, or to all connections 371 along the chain. Although the diagram is linear, each participant may 372 be engaged in multiple, simultaneous communications. For example, B 373 may be receiving requests from many clients other than A, and/or 374 forwarding requests to servers other than C, at the same time that it 375 is handling A's request. 376 </t> 377 <t> 378 Any party to the communication which is not acting as a tunnel may 379 employ an internal cache for handling requests. The effect of a cache 380 is that the request/response chain is shortened if one of the 381 participants along the chain has a cached response applicable to that 382 request. The following illustrates the resulting chain if B has a 383 cached copy of an earlier response from O (via C) for a request which 384 has not been cached by UA or A. 385 </t> 386 <figure><artwork type="drawing"> 387 request chain ----------> 388 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 389 <--------- response chain 390 </artwork></figure> 391 <t> 392 Not all responses are usefully cacheable, and some requests may 393 contain modifiers which place special requirements on cache behavior. 394 HTTP requirements for cache behavior and cacheable responses are 395 defined in &caching;. 396 </t> 397 <t> 398 In fact, there are a wide variety of architectures and configurations 399 of caches and proxies currently being experimented with or deployed 400 across the World Wide Web. These systems include national hierarchies 401 of proxy caches to save transoceanic bandwidth, systems that 402 broadcast or multicast cache entries, organizations that distribute 403 subsets of cached data via CD-ROM, and so on. HTTP systems are used 404 in corporate intranets over high-bandwidth links, and for access via 405 PDAs with low-power radio links and intermittent connectivity. The 406 goal of HTTP/1.1 is to support the wide diversity of configurations 407 already deployed while introducing protocol constructs that meet the 408 needs of those who build web applications that require high 409 reliability and, failing that, at least reliable indications of 410 failure. 411 </t> 412 <t> 413 HTTP communication usually takes place over TCP/IP connections. The 414 default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does 415 not preclude HTTP from being implemented on top of any other protocol 416 on the Internet, or on other networks. HTTP only presumes a reliable 417 transport; any protocol that provides such guarantees can be used; 418 the mapping of the HTTP/1.1 request and response structures onto the 419 transport data units of the protocol in question is outside the scope 420 of this specification. 421 </t> 422 <t> 423 In HTTP/1.0, most implementations used a new connection for each 424 request/response exchange. In HTTP/1.1, a connection may be used for 425 one or more request/response exchanges, although connections may be 426 closed for a variety of reasons (see <xref target="persistent.connections"/>). 427 </t> 428 </section> 429 </section> 430 431 <section title="Notational Conventions and Generic Grammar" anchor="notation"> 316 <t anchor="core.rules"> 317 <x:anchor-alias value="OCTET"/> 318 <x:anchor-alias value="CHAR"/> 319 <x:anchor-alias value="ALPHA"/> 320 <x:anchor-alias value="DIGIT"/> 321 <x:anchor-alias value="CTL"/> 322 <x:anchor-alias value="CR"/> 323 <x:anchor-alias value="LF"/> 324 <x:anchor-alias value="SP"/> 325 <x:anchor-alias value="HTAB"/> 326 <x:anchor-alias value="DQUOTE"/> 327 The following rules are used throughout this specification to 328 describe basic parsing constructs. The US-ASCII coded character set 329 is defined by ANSI X3.4-1986 <xref target="USASCII"/>. 330 </t> 331 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="OCTET"/><iref primary="true" item="Grammar" subitem="CHAR"/><iref primary="true" item="Grammar" subitem="ALPHA"/><iref primary="true" item="Grammar" subitem="DIGIT"/><iref primary="true" item="Grammar" subitem="CTL"/><iref primary="true" item="Grammar" subitem="CR"/><iref primary="true" item="Grammar" subitem="LF"/><iref primary="true" item="Grammar" subitem="SP"/><iref primary="true" item="Grammar" subitem="HTAB"/><iref primary="true" item="Grammar" subitem="DQUOTE"/> 332 <x:ref>OCTET</x:ref> = %x00-FF 333 ; any 8-bit sequence of data 334 <x:ref>CHAR</x:ref> = %x01-7F 335 ; any US-ASCII character, excluding NUL 336 <x:ref>ALPHA</x:ref> = %x41-5A / %x61-7A 337 ; A-Z / a-z 338 <x:ref>DIGIT</x:ref> = %x30-39 339 ; any US-ASCII digit "0".."9" 340 <x:ref>CTL</x:ref> = %x00-1F / %x7F 341 ; (octets 0 - 31) and DEL (127) 342 <x:ref>CR</x:ref> = %x0D 343 ; US-ASCII CR, carriage return (13) 344 <x:ref>LF</x:ref> = %x0A 345 ; US-ASCII LF, linefeed (10) 346 <x:ref>SP</x:ref> = %x20 347 ; US-ASCII SP, space (32) 348 <x:ref>HTAB</x:ref> = %x09 349 ; US-ASCII HT, horizontal-tab (9) 350 <x:ref>DQUOTE</x:ref> = %x22 351 ; US-ASCII double-quote mark (34) 352 </artwork></figure> 432 353 433 354 <section title="Augmented BNF" anchor="notation.abnf"> … … 483 404 484 405 <section title="Basic Rules" anchor="basic.rules"> 485 <t anchor="core.rules">486 <x:anchor-alias value="OCTET"/>487 <x:anchor-alias value="CHAR"/>488 <x:anchor-alias value="ALPHA"/>489 <x:anchor-alias value="DIGIT"/>490 <x:anchor-alias value="CTL"/>491 <x:anchor-alias value="CR"/>492 <x:anchor-alias value="LF"/>493 <x:anchor-alias value="SP"/>494 <x:anchor-alias value="HTAB"/>495 <x:anchor-alias value="DQUOTE"/>496 The following rules are used throughout this specification to497 describe basic parsing constructs. The US-ASCII coded character set498 is defined by ANSI X3.4-1986 <xref target="USASCII"/>.499 </t>500 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="OCTET"/><iref primary="true" item="Grammar" subitem="CHAR"/><iref primary="true" item="Grammar" subitem="ALPHA"/><iref primary="true" item="Grammar" subitem="DIGIT"/><iref primary="true" item="Grammar" subitem="CTL"/><iref primary="true" item="Grammar" subitem="CR"/><iref primary="true" item="Grammar" subitem="LF"/><iref primary="true" item="Grammar" subitem="SP"/><iref primary="true" item="Grammar" subitem="HTAB"/><iref primary="true" item="Grammar" subitem="DQUOTE"/>501 <x:ref>OCTET</x:ref> = %x00-FF502 ; any 8-bit sequence of data503 <x:ref>CHAR</x:ref> = %x01-7F504 ; any US-ASCII character, excluding NUL505 <x:ref>ALPHA</x:ref> = %x41-5A / %x61-7A506 ; A-Z / a-z507 <x:ref>DIGIT</x:ref> = %x30-39508 ; any US-ASCII digit "0".."9"509 <x:ref>CTL</x:ref> = %x00-1F / %x7F510 ; (octets 0 - 31) and DEL (127)511 <x:ref>CR</x:ref> = %x0D512 ; US-ASCII CR, carriage return (13)513 <x:ref>LF</x:ref> = %x0A514 ; US-ASCII LF, linefeed (10)515 <x:ref>SP</x:ref> = %x20516 ; US-ASCII SP, space (32)517 <x:ref>HTAB</x:ref> = %x09518 ; US-ASCII HT, horizontal-tab (9)519 <x:ref>DQUOTE</x:ref> = %x22520 ; US-ASCII double-quote mark (34)521 </artwork></figure>522 406 <t anchor="rule.CRLF"> 523 407 <x:anchor-alias value="CRLF"/> … … 653 537 </section> 654 538 539 </section> 540 </section> 541 542 <section title="When to use HTTP" anchor="when"> 543 544 <section title="Uniform Resource Identifiers" anchor="uri"> 545 <t> 546 URIs have been known by many names: WWW addresses, Universal Document 547 Identifiers, Universal Resource Identifiers <xref target="RFC1630"/>, and finally the 548 combination of Uniform Resource Locators (URL) <xref target="RFC1738"/> and Names (URN) 549 <xref target="RFC1737"/>. As far as HTTP is concerned, Uniform Resource Identifiers are 550 simply formatted strings which identify--via name, location, or any 551 other characteristic--a resource. 552 </t> 553 554 <section title="General Syntax" anchor="general.syntax"> 555 <x:anchor-alias value="absoluteURI"/> 556 <x:anchor-alias value="authority"/> 557 <x:anchor-alias value="fragment"/> 558 <x:anchor-alias value="path-absolute"/> 559 <x:anchor-alias value="port"/> 560 <x:anchor-alias value="query"/> 561 <x:anchor-alias value="relativeURI"/> 562 <x:anchor-alias value="uri-host"/> 563 <t> 564 URIs in HTTP can be represented in absolute form or relative to some 565 known base URI <xref target="RFC1808"/>, depending upon the context of their use. The two 566 forms are differentiated by the fact that absolute URIs always begin 567 with a scheme name followed by a colon. For definitive information on 568 URL syntax and semantics, see "Uniform Resource Identifiers (URI): 569 Generic Syntax and Semantics," <xref target="RFC2396"/> (which replaces <xref target="RFC1738"/> 570 and <xref target="RFC1808"/>). This specification adopts the 571 definitions of "URI-reference", "absoluteURI", "fragment", "relativeURI", "port", 572 "host", "abs_path", "query", and "authority" from that specification: 573 </t> 574 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="absoluteURI"/><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="relativeURI"/><iref primary="true" item="Grammar" subitem="uri-host"/> 575 <x:ref>absoluteURI</x:ref> = <absoluteURI, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>> 576 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2"/>> 577 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC2396" x:fmt="," x:sec="4.1"/>> 578 <x:ref>path-absolute</x:ref> = <abs_path, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>> 579 <x:ref>port</x:ref> = <port, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>> 580 <x:ref>query</x:ref> = <query, defined in <xref target="RFC2396" x:fmt="," x:sec="3.4"/>> 581 <x:ref>relativeURI</x:ref> = <relativeURI, defined in <xref target="RFC2396" x:fmt="," x:sec="5"/>> 582 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>> 583 </artwork></figure> 584 <t> 585 HTTP does not place any a priori limit on the length of 586 a URI. Servers &MUST; be able to handle the URI of any resource they 587 serve, and &SHOULD; be able to handle URIs of unbounded length if they 588 provide GET-based forms that could generate such URIs. A server 589 &SHOULD; return 414 (Request-URI Too Long) status if a URI is longer 590 than the server can handle (see &status-414;). 591 </t> 592 <t> 593 <list> 594 <t> 595 <x:h>Note:</x:h> Servers ought to be cautious about depending on URI lengths 596 above 255 bytes, because some older client or proxy 597 implementations might not properly support these lengths. 598 </t> 599 </list> 600 </t> 601 </section> 602 603 <section title="http URL" anchor="http.url"> 604 <x:anchor-alias value="http-URL"/> 605 <iref item="http URI scheme" primary="true"/> 606 <iref item="URI scheme" subitem="http" primary="true"/> 607 <t> 608 The "http" scheme is used to locate network resources via the HTTP 609 protocol. This section defines the scheme-specific syntax and 610 semantics for http URLs. 611 </t> 612 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URL"/> 613 <x:ref>http-URL</x:ref> = "http:" "//" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] 614 [ <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ]] 615 </artwork></figure> 616 <t> 617 If the port is empty or not given, port 80 is assumed. The semantics 618 are that the identified resource is located at the server listening 619 for TCP connections on that port of that host, and the Request-URI 620 for the resource is path-absolute (<xref target="request-uri"/>). The use of IP addresses 621 in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If 622 the path-absolute is not present in the URL, it &MUST; be given as "/" when 623 used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy 624 receives a host name which is not a fully qualified domain name, it 625 &MAY; add its domain to the host name it received. If a proxy receives 626 a fully qualified domain name, the proxy &MUST-NOT; change the host 627 name. 628 </t> 629 <t><list><t> 630 <iref item="https URI scheme"/> 631 <iref item="URI scheme" subitem="https"/> 632 <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>. 633 </t></list></t> 634 </section> 635 636 <section title="URI Comparison" anchor="uri.comparison"> 637 <t> 638 When comparing two URIs to decide if they match or not, a client 639 &SHOULD; use a case-sensitive octet-by-octet comparison of the entire 640 URIs, with these exceptions: 641 <list style="symbols"> 642 <t>A port that is empty or not given is equivalent to the default 643 port for that URI-reference;</t> 644 <t>Comparisons of host names &MUST; be case-insensitive;</t> 645 <t>Comparisons of scheme names &MUST; be case-insensitive;</t> 646 <t>An empty path-absolute is equivalent to an path-absolute of "/".</t> 647 </list> 648 </t> 649 <t> 650 Characters other than those in the "reserved" set (see 651 <xref target="RFC2396" x:fmt="," x:sec="2.2"/>) are equivalent to their 652 ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding. 653 </t> 654 <t> 655 For example, the following three URIs are equivalent: 656 </t> 657 <figure><artwork type="example"> 658 http://example.com:80/~smith/home.html 659 http://EXAMPLE.com/%7Esmith/home.html 660 http://EXAMPLE.com:/%7esmith/home.html 661 </artwork></figure> 662 </section> 663 </section> 664 665 <section title="Overall Operation" anchor="intro.overall.operation"> 666 <t> 667 HTTP is a request/response protocol. A client sends a 668 request to the server in the form of a request method, URI, and 669 protocol version, followed by a MIME-like message containing request 670 modifiers, client information, and possible body content over a 671 connection with a server. The server responds with a status line, 672 including the message's protocol version and a success or error code, 673 followed by a MIME-like message containing server information, entity 674 metainformation, and possible entity-body content. The relationship 675 between HTTP and MIME is described in &diff2045entity;. 676 </t> 677 <t> 678 Most HTTP communication is initiated by a user agent and consists of 679 a request to be applied to a resource on some origin server. In the 680 simplest case, this may be accomplished via a single connection (v) 681 between the user agent (UA) and the origin server (O). 682 </t> 683 <figure><artwork type="drawing"> 684 request chain ------------------------> 685 UA -------------------v------------------- O 686 <----------------------- response chain 687 </artwork></figure> 688 <t> 689 A more complicated situation occurs when one or more intermediaries 690 are present in the request/response chain. There are three common 691 forms of intermediary: proxy, gateway, and tunnel. A proxy is a 692 forwarding agent, receiving requests for a URI in its absolute form, 693 rewriting all or part of the message, and forwarding the reformatted 694 request toward the server identified by the URI. A gateway is a 695 receiving agent, acting as a layer above some other server(s) and, if 696 necessary, translating the requests to the underlying server's 697 protocol. A tunnel acts as a relay point between two connections 698 without changing the messages; tunnels are used when the 699 communication needs to pass through an intermediary (such as a 700 firewall) even when the intermediary cannot understand the contents 701 of the messages. 702 </t> 703 <figure><artwork type="drawing"> 704 request chain --------------------------------------> 705 UA -----v----- A -----v----- B -----v----- C -----v----- O 706 <------------------------------------- response chain 707 </artwork></figure> 708 <t> 709 The figure above shows three intermediaries (A, B, and C) between the 710 user agent and origin server. A request or response message that 711 travels the whole chain will pass through four separate connections. 712 This distinction is important because some HTTP communication options 713 may apply only to the connection with the nearest, non-tunnel 714 neighbor, only to the end-points of the chain, or to all connections 715 along the chain. Although the diagram is linear, each participant may 716 be engaged in multiple, simultaneous communications. For example, B 717 may be receiving requests from many clients other than A, and/or 718 forwarding requests to servers other than C, at the same time that it 719 is handling A's request. 720 </t> 721 <t> 722 Any party to the communication which is not acting as a tunnel may 723 employ an internal cache for handling requests. The effect of a cache 724 is that the request/response chain is shortened if one of the 725 participants along the chain has a cached response applicable to that 726 request. The following illustrates the resulting chain if B has a 727 cached copy of an earlier response from O (via C) for a request which 728 has not been cached by UA or A. 729 </t> 730 <figure><artwork type="drawing"> 731 request chain ----------> 732 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 733 <--------- response chain 734 </artwork></figure> 735 <t> 736 Not all responses are usefully cacheable, and some requests may 737 contain modifiers which place special requirements on cache behavior. 738 HTTP requirements for cache behavior and cacheable responses are 739 defined in &caching;. 740 </t> 741 <t> 742 In fact, there are a wide variety of architectures and configurations 743 of caches and proxies currently being experimented with or deployed 744 across the World Wide Web. These systems include national hierarchies 745 of proxy caches to save transoceanic bandwidth, systems that 746 broadcast or multicast cache entries, organizations that distribute 747 subsets of cached data via CD-ROM, and so on. HTTP systems are used 748 in corporate intranets over high-bandwidth links, and for access via 749 PDAs with low-power radio links and intermittent connectivity. The 750 goal of HTTP/1.1 is to support the wide diversity of configurations 751 already deployed while introducing protocol constructs that meet the 752 needs of those who build web applications that require high 753 reliability and, failing that, at least reliable indications of 754 failure. 755 </t> 756 <t> 757 HTTP communication usually takes place over TCP/IP connections. The 758 default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does 759 not preclude HTTP from being implemented on top of any other protocol 760 on the Internet, or on other networks. HTTP only presumes a reliable 761 transport; any protocol that provides such guarantees can be used; 762 the mapping of the HTTP/1.1 request and response structures onto the 763 transport data units of the protocol in question is outside the scope 764 of this specification. 765 </t> 766 <t> 767 In HTTP/1.0, most implementations used a new connection for each 768 request/response exchange. In HTTP/1.1, a connection may be used for 769 one or more request/response exchanges, although connections may be 770 closed for a variety of reasons (see <xref target="persistent.connections"/>). 771 </t> 772 </section> 655 773 </section> 656 774 … … 728 846 </list> 729 847 </t> 730 </section>731 732 <section title="Uniform Resource Identifiers" anchor="uri">733 <t>734 URIs have been known by many names: WWW addresses, Universal Document735 Identifiers, Universal Resource Identifiers <xref target="RFC1630"/>, and finally the736 combination of Uniform Resource Locators (URL) <xref target="RFC1738"/> and Names (URN)737 <xref target="RFC1737"/>. As far as HTTP is concerned, Uniform Resource Identifiers are738 simply formatted strings which identify--via name, location, or any739 other characteristic--a resource.740 </t>741 742 <section title="General Syntax" anchor="general.syntax">743 <x:anchor-alias value="absoluteURI"/>744 <x:anchor-alias value="authority"/>745 <x:anchor-alias value="fragment"/>746 <x:anchor-alias value="path-absolute"/>747 <x:anchor-alias value="port"/>748 <x:anchor-alias value="query"/>749 <x:anchor-alias value="relativeURI"/>750 <x:anchor-alias value="uri-host"/>751 <t>752 URIs in HTTP can be represented in absolute form or relative to some753 known base URI <xref target="RFC1808"/>, depending upon the context of their use. The two754 forms are differentiated by the fact that absolute URIs always begin755 with a scheme name followed by a colon. For definitive information on756 URL syntax and semantics, see "Uniform Resource Identifiers (URI):757 Generic Syntax and Semantics," <xref target="RFC2396"/> (which replaces <xref target="RFC1738"/>758 and <xref target="RFC1808"/>). This specification adopts the759 definitions of "URI-reference", "absoluteURI", "fragment", "relativeURI", "port",760 "host", "abs_path", "query", and "authority" from that specification:761 </t>762 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="absoluteURI"/><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="relativeURI"/><iref primary="true" item="Grammar" subitem="uri-host"/>763 <x:ref>absoluteURI</x:ref> = <absoluteURI, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>>764 <x:ref>authority</x:ref> = <authority, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2"/>>765 <x:ref>fragment</x:ref> = <fragment, defined in <xref target="RFC2396" x:fmt="," x:sec="4.1"/>>766 <x:ref>path-absolute</x:ref> = <abs_path, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>>767 <x:ref>port</x:ref> = <port, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>>768 <x:ref>query</x:ref> = <query, defined in <xref target="RFC2396" x:fmt="," x:sec="3.4"/>>769 <x:ref>relativeURI</x:ref> = <relativeURI, defined in <xref target="RFC2396" x:fmt="," x:sec="5"/>>770 <x:ref>uri-host</x:ref> = <host, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>>771 </artwork></figure>772 <t>773 HTTP does not place any a priori limit on the length of774 a URI. Servers &MUST; be able to handle the URI of any resource they775 serve, and &SHOULD; be able to handle URIs of unbounded length if they776 provide GET-based forms that could generate such URIs. A server777 &SHOULD; return 414 (Request-URI Too Long) status if a URI is longer778 than the server can handle (see &status-414;).779 </t>780 <t>781 <list>782 <t>783 <x:h>Note:</x:h> Servers ought to be cautious about depending on URI lengths784 above 255 bytes, because some older client or proxy785 implementations might not properly support these lengths.786 </t>787 </list>788 </t>789 </section>790 791 <section title="http URL" anchor="http.url">792 <x:anchor-alias value="http-URL"/>793 <iref item="http URI scheme" primary="true"/>794 <iref item="URI scheme" subitem="http" primary="true"/>795 <t>796 The "http" scheme is used to locate network resources via the HTTP797 protocol. This section defines the scheme-specific syntax and798 semantics for http URLs.799 </t>800 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URL"/>801 <x:ref>http-URL</x:ref> = "http:" "//" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ]802 [ <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ]]803 </artwork></figure>804 <t>805 If the port is empty or not given, port 80 is assumed. The semantics806 are that the identified resource is located at the server listening807 for TCP connections on that port of that host, and the Request-URI808 for the resource is path-absolute (<xref target="request-uri"/>). The use of IP addresses809 in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If810 the path-absolute is not present in the URL, it &MUST; be given as "/" when811 used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy812 receives a host name which is not a fully qualified domain name, it813 &MAY; add its domain to the host name it received. If a proxy receives814 a fully qualified domain name, the proxy &MUST-NOT; change the host815 name.816 </t>817 <t><list><t>818 <iref item="https URI scheme"/>819 <iref item="URI scheme" subitem="https"/>820 <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>.821 </t></list></t>822 </section>823 824 <section title="URI Comparison" anchor="uri.comparison">825 <t>826 When comparing two URIs to decide if they match or not, a client827 &SHOULD; use a case-sensitive octet-by-octet comparison of the entire828 URIs, with these exceptions:829 <list style="symbols">830 <t>A port that is empty or not given is equivalent to the default831 port for that URI-reference;</t>832 <t>Comparisons of host names &MUST; be case-insensitive;</t>833 <t>Comparisons of scheme names &MUST; be case-insensitive;</t>834 <t>An empty path-absolute is equivalent to an path-absolute of "/".</t>835 </list>836 </t>837 <t>838 Characters other than those in the "reserved" set (see839 <xref target="RFC2396" x:fmt="," x:sec="2.2"/>) are equivalent to their840 ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding.841 </t>842 <t>843 For example, the following three URIs are equivalent:844 </t>845 <figure><artwork type="example">846 http://example.com:80/~smith/home.html847 http://EXAMPLE.com/%7Esmith/home.html848 http://EXAMPLE.com:/%7esmith/home.html849 </artwork></figure>850 </section>851 848 </section> 852 849
Note: See TracChangeset
for help on using the changeset viewer.