Changeset 391
- Timestamp:
- 15/11/08 00:44:55 (14 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 10 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r390 r391 365 365 <link rel="Index" href="#rfc.index"> 366 366 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 367 <link rel="Chapter" title="2 Protocol Parameters" href="#rfc.section.2"> 368 <link rel="Chapter" title="3 HTTP Message" href="#rfc.section.3"> 369 <link rel="Chapter" title="4 Request" href="#rfc.section.4"> 370 <link rel="Chapter" title="5 Response" href="#rfc.section.5"> 371 <link rel="Chapter" title="6 Connections" href="#rfc.section.6"> 372 <link rel="Chapter" title="7 Header Field Definitions" href="#rfc.section.7"> 373 <link rel="Chapter" title="8 IANA Considerations" href="#rfc.section.8"> 374 <link rel="Chapter" title="9 Security Considerations" href="#rfc.section.9"> 375 <link rel="Chapter" title="10 Acknowledgments" href="#rfc.section.10"> 376 <link rel="Chapter" href="#rfc.section.11" title="11 References"> 367 <link rel="Chapter" title="2 HTTP architecture" href="#rfc.section.2"> 368 <link rel="Chapter" title="3 Protocol Parameters" href="#rfc.section.3"> 369 <link rel="Chapter" title="4 HTTP Message" href="#rfc.section.4"> 370 <link rel="Chapter" title="5 Request" href="#rfc.section.5"> 371 <link rel="Chapter" title="6 Response" href="#rfc.section.6"> 372 <link rel="Chapter" title="7 Connections" href="#rfc.section.7"> 373 <link rel="Chapter" title="8 Header Field Definitions" href="#rfc.section.8"> 374 <link rel="Chapter" title="9 IANA Considerations" href="#rfc.section.9"> 375 <link rel="Chapter" title="10 Security Considerations" href="#rfc.section.10"> 376 <link rel="Chapter" title="11 Acknowledgments" href="#rfc.section.11"> 377 <link rel="Chapter" href="#rfc.section.12" title="12 References"> 377 378 <link rel="Appendix" title="A Tolerant Applications" href="#rfc.section.A"> 378 379 <link rel="Appendix" title="B Compatibility with Previous Versions" href="#rfc.section.B"> … … 521 522 </ul> 522 523 </li> 523 <li class="tocline1">1.3 <a href="#intro.overall.operation">Overall Operation</a></li>524 524 </ul> 525 525 </li> 526 <li class="tocline0">2. <a href="# protocol.parameters">Protocol Parameters</a><ul class="toc">527 <li class="tocline1">2.1 <a href="# http.version">HTTP Version</a></li>528 <li class="tocline1">2.2 <a href="#uri">Uniform Resource Identifiers</a><ul class="toc">529 <li class="tocline1">2. 2.1 <a href="#http.uri">http URI scheme</a></li>530 <li class="tocline1">2. 2.2 <a href="#uri.comparison">URI Comparison</a></li>526 <li class="tocline0">2. <a href="#architecture">HTTP architecture</a><ul class="toc"> 527 <li class="tocline1">2.1 <a href="#uri">Uniform Resource Identifiers</a><ul class="toc"> 528 <li class="tocline1">2.1.1 <a href="#http.uri">http URI scheme</a></li> 529 <li class="tocline1">2.1.2 <a href="#uri.comparison">URI Comparison</a></li> 530 <li class="tocline1">2.1.3 <a href="#scheme.aliases">Scheme aliases considered harmful</a></li> 531 531 </ul> 532 532 </li> 533 <li class="tocline1">2.3 <a href="#date.time.formats">Date/Time Formats</a><ul class="toc"> 534 <li class="tocline1">2.3.1 <a href="#full.date">Full Date</a></li> 533 <li class="tocline1">2.2 <a href="#intro.overall.operation">Overall Operation</a></li> 534 <li class="tocline1">2.3 <a href="#http.proxy">Use of HTTP for proxy communication</a></li> 535 <li class="tocline1">2.4 <a href="#http.intercept">Interception of HTTP for access control</a></li> 536 <li class="tocline1">2.5 <a href="#http.others">Use of HTTP by other protocols</a></li> 537 <li class="tocline1">2.6 <a href="#http.media">Use of HTTP by media type specification</a></li> 538 </ul> 539 </li> 540 <li class="tocline0">3. <a href="#protocol.parameters">Protocol Parameters</a><ul class="toc"> 541 <li class="tocline1">3.1 <a href="#http.version">HTTP Version</a></li> 542 <li class="tocline1">3.2 <a href="#date.time.formats">Date/Time Formats</a><ul class="toc"> 543 <li class="tocline1">3.2.1 <a href="#full.date">Full Date</a></li> 535 544 </ul> 536 545 </li> 537 <li class="tocline1"> 2.4 <a href="#transfer.codings">Transfer Codings</a><ul class="toc">538 <li class="tocline1"> 2.4.1 <a href="#chunked.transfer.encoding">Chunked Transfer Coding</a></li>546 <li class="tocline1">3.3 <a href="#transfer.codings">Transfer Codings</a><ul class="toc"> 547 <li class="tocline1">3.3.1 <a href="#chunked.transfer.encoding">Chunked Transfer Coding</a></li> 539 548 </ul> 540 549 </li> 541 <li class="tocline1"> 2.5 <a href="#product.tokens">Product Tokens</a></li>550 <li class="tocline1">3.4 <a href="#product.tokens">Product Tokens</a></li> 542 551 </ul> 543 552 </li> 544 <li class="tocline0"> 3. <a href="#http.message">HTTP Message</a><ul class="toc">545 <li class="tocline1"> 3.1 <a href="#message.types">Message Types</a></li>546 <li class="tocline1"> 3.2 <a href="#message.headers">Message Headers</a></li>547 <li class="tocline1"> 3.3 <a href="#message.body">Message Body</a></li>548 <li class="tocline1"> 3.4 <a href="#message.length">Message Length</a></li>549 <li class="tocline1"> 3.5 <a href="#general.header.fields">General Header Fields</a></li>553 <li class="tocline0">4. <a href="#http.message">HTTP Message</a><ul class="toc"> 554 <li class="tocline1">4.1 <a href="#message.types">Message Types</a></li> 555 <li class="tocline1">4.2 <a href="#message.headers">Message Headers</a></li> 556 <li class="tocline1">4.3 <a href="#message.body">Message Body</a></li> 557 <li class="tocline1">4.4 <a href="#message.length">Message Length</a></li> 558 <li class="tocline1">4.5 <a href="#general.header.fields">General Header Fields</a></li> 550 559 </ul> 551 560 </li> 552 <li class="tocline0"> 4. <a href="#request">Request</a><ul class="toc">553 <li class="tocline1"> 4.1 <a href="#request-line">Request-Line</a><ul class="toc">554 <li class="tocline1"> 4.1.1 <a href="#method">Method</a></li>555 <li class="tocline1"> 4.1.2 <a href="#request-uri">Request-URI</a></li>561 <li class="tocline0">5. <a href="#request">Request</a><ul class="toc"> 562 <li class="tocline1">5.1 <a href="#request-line">Request-Line</a><ul class="toc"> 563 <li class="tocline1">5.1.1 <a href="#method">Method</a></li> 564 <li class="tocline1">5.1.2 <a href="#request-target">request-target</a></li> 556 565 </ul> 557 566 </li> 558 <li class="tocline1"> 4.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>567 <li class="tocline1">5.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li> 559 568 </ul> 560 569 </li> 561 <li class="tocline0"> 5. <a href="#response">Response</a><ul class="toc">562 <li class="tocline1"> 5.1 <a href="#status-line">Status-Line</a><ul class="toc">563 <li class="tocline1"> 5.1.1 <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li>570 <li class="tocline0">6. <a href="#response">Response</a><ul class="toc"> 571 <li class="tocline1">6.1 <a href="#status-line">Status-Line</a><ul class="toc"> 572 <li class="tocline1">6.1.1 <a href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></li> 564 573 </ul> 565 574 </li> 566 575 </ul> 567 576 </li> 568 <li class="tocline0"> 6. <a href="#connections">Connections</a><ul class="toc">569 <li class="tocline1"> 6.1 <a href="#persistent.connections">Persistent Connections</a><ul class="toc">570 <li class="tocline1"> 6.1.1 <a href="#persistent.purpose">Purpose</a></li>571 <li class="tocline1"> 6.1.2 <a href="#persistent.overall">Overall Operation</a><ul class="toc">572 <li class="tocline1"> 6.1.2.1 <a href="#persistent.negotiation">Negotiation</a></li>573 <li class="tocline1"> 6.1.2.2 <a href="#pipelining">Pipelining</a></li>577 <li class="tocline0">7. <a href="#connections">Connections</a><ul class="toc"> 578 <li class="tocline1">7.1 <a href="#persistent.connections">Persistent Connections</a><ul class="toc"> 579 <li class="tocline1">7.1.1 <a href="#persistent.purpose">Purpose</a></li> 580 <li class="tocline1">7.1.2 <a href="#persistent.overall">Overall Operation</a><ul class="toc"> 581 <li class="tocline1">7.1.2.1 <a href="#persistent.negotiation">Negotiation</a></li> 582 <li class="tocline1">7.1.2.2 <a href="#pipelining">Pipelining</a></li> 574 583 </ul> 575 584 </li> 576 <li class="tocline1"> 6.1.3 <a href="#persistent.proxy">Proxy Servers</a></li>577 <li class="tocline1"> 6.1.4 <a href="#persistent.practical">Practical Considerations</a></li>585 <li class="tocline1">7.1.3 <a href="#persistent.proxy">Proxy Servers</a></li> 586 <li class="tocline1">7.1.4 <a href="#persistent.practical">Practical Considerations</a></li> 578 587 </ul> 579 588 </li> 580 <li class="tocline1"> 6.2 <a href="#message.transmission.requirements">Message Transmission Requirements</a><ul class="toc">581 <li class="tocline1"> 6.2.1 <a href="#persistent.flow">Persistent Connections and Flow Control</a></li>582 <li class="tocline1"> 6.2.2 <a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li>583 <li class="tocline1"> 6.2.3 <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li>584 <li class="tocline1"> 6.2.4 <a href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></li>589 <li class="tocline1">7.2 <a href="#message.transmission.requirements">Message Transmission Requirements</a><ul class="toc"> 590 <li class="tocline1">7.2.1 <a href="#persistent.flow">Persistent Connections and Flow Control</a></li> 591 <li class="tocline1">7.2.2 <a href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></li> 592 <li class="tocline1">7.2.3 <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li> 593 <li class="tocline1">7.2.4 <a href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></li> 585 594 </ul> 586 595 </li> 587 596 </ul> 588 597 </li> 589 <li class="tocline0"> 7. <a href="#header.fields">Header Field Definitions</a><ul class="toc">590 <li class="tocline1"> 7.1 <a href="#header.connection">Connection</a></li>591 <li class="tocline1"> 7.2 <a href="#header.content-length">Content-Length</a></li>592 <li class="tocline1"> 7.3 <a href="#header.date">Date</a><ul class="toc">593 <li class="tocline1"> 7.3.1 <a href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></li>598 <li class="tocline0">8. <a href="#header.fields">Header Field Definitions</a><ul class="toc"> 599 <li class="tocline1">8.1 <a href="#header.connection">Connection</a></li> 600 <li class="tocline1">8.2 <a href="#header.content-length">Content-Length</a></li> 601 <li class="tocline1">8.3 <a href="#header.date">Date</a><ul class="toc"> 602 <li class="tocline1">8.3.1 <a href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></li> 594 603 </ul> 595 604 </li> 596 <li class="tocline1"> 7.4 <a href="#header.host">Host</a></li>597 <li class="tocline1"> 7.5 <a href="#header.te">TE</a></li>598 <li class="tocline1"> 7.6 <a href="#header.trailer">Trailer</a></li>599 <li class="tocline1"> 7.7 <a href="#header.transfer-encoding">Transfer-Encoding</a></li>600 <li class="tocline1"> 7.8 <a href="#header.upgrade">Upgrade</a></li>601 <li class="tocline1"> 7.9 <a href="#header.via">Via</a></li>605 <li class="tocline1">8.4 <a href="#header.host">Host</a></li> 606 <li class="tocline1">8.5 <a href="#header.te">TE</a></li> 607 <li class="tocline1">8.6 <a href="#header.trailer">Trailer</a></li> 608 <li class="tocline1">8.7 <a href="#header.transfer-encoding">Transfer-Encoding</a></li> 609 <li class="tocline1">8.8 <a href="#header.upgrade">Upgrade</a></li> 610 <li class="tocline1">8.9 <a href="#header.via">Via</a></li> 602 611 </ul> 603 612 </li> 604 <li class="tocline0"> 8. <a href="#IANA.considerations">IANA Considerations</a><ul class="toc">605 <li class="tocline1"> 8.1 <a href="#message.header.registration">Message Header Registration</a></li>606 <li class="tocline1"> 8.2 <a href="#uri.scheme.registration">URI Scheme Registration</a></li>607 <li class="tocline1"> 8.3 <a href="#internet.media.type.http">Internet Media Type Registrations</a><ul class="toc">608 <li class="tocline1"> 8.3.1 <a href="#internet.media.type.message.http">Internet Media Type message/http</a></li>609 <li class="tocline1"> 8.3.2 <a href="#internet.media.type.application.http">Internet Media Type application/http</a></li>613 <li class="tocline0">9. <a href="#IANA.considerations">IANA Considerations</a><ul class="toc"> 614 <li class="tocline1">9.1 <a href="#message.header.registration">Message Header Registration</a></li> 615 <li class="tocline1">9.2 <a href="#uri.scheme.registration">URI Scheme Registration</a></li> 616 <li class="tocline1">9.3 <a href="#internet.media.type.http">Internet Media Type Registrations</a><ul class="toc"> 617 <li class="tocline1">9.3.1 <a href="#internet.media.type.message.http">Internet Media Type message/http</a></li> 618 <li class="tocline1">9.3.2 <a href="#internet.media.type.application.http">Internet Media Type application/http</a></li> 610 619 </ul> 611 620 </li> 612 621 </ul> 613 622 </li> 614 <li class="tocline0"> 9. <a href="#security.considerations">Security Considerations</a><ul class="toc">615 <li class="tocline1"> 9.1 <a href="#personal.information">Personal Information</a></li>616 <li class="tocline1"> 9.2 <a href="#abuse.of.server.log.information">Abuse of Server Log Information</a></li>617 <li class="tocline1"> 9.3 <a href="#attack.pathname">Attacks Based On File and Path Names</a></li>618 <li class="tocline1"> 9.4 <a href="#dns.spoofing">DNS Spoofing</a></li>619 <li class="tocline1"> 9.5 <a href="#attack.proxies">Proxies and Caching</a></li>620 <li class="tocline1"> 9.6 <a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li>623 <li class="tocline0">10. <a href="#security.considerations">Security Considerations</a><ul class="toc"> 624 <li class="tocline1">10.1 <a href="#personal.information">Personal Information</a></li> 625 <li class="tocline1">10.2 <a href="#abuse.of.server.log.information">Abuse of Server Log Information</a></li> 626 <li class="tocline1">10.3 <a href="#attack.pathname">Attacks Based On File and Path Names</a></li> 627 <li class="tocline1">10.4 <a href="#dns.spoofing">DNS Spoofing</a></li> 628 <li class="tocline1">10.5 <a href="#attack.proxies">Proxies and Caching</a></li> 629 <li class="tocline1">10.6 <a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li> 621 630 </ul> 622 631 </li> 623 <li class="tocline0">1 0. <a href="#ack">Acknowledgments</a></li>624 <li class="tocline0">1 1. <a href="#rfc.references">References</a><ul class="toc">625 <li class="tocline1">1 1.1 <a href="#rfc.references.1">Normative References</a></li>626 <li class="tocline1">1 1.2 <a href="#rfc.references.2">Informative References</a></li>632 <li class="tocline0">11. <a href="#ack">Acknowledgments</a></li> 633 <li class="tocline0">12. <a href="#rfc.references">References</a><ul class="toc"> 634 <li class="tocline1">12.1 <a href="#rfc.references.1">Normative References</a></li> 635 <li class="tocline1">12.2 <a href="#rfc.references.2">Informative References</a></li> 627 636 </ul> 628 637 </li> … … 655 664 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 656 665 <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and 657 MIME-like message payloads for flexible interaction with network-based hypermedia information systems. HTTP relies upon the 658 Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate resource targets for interaction and to identify other resources. Messages are passed in a format similar to that 659 used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages). 660 </p> 661 <p id="rfc.section.1.p.2">HTTP is also designed for use as a generic protocol for translating communication to and from other Internet information systems, 666 MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the 667 Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate resource targets and relationships between resources. Messages are passed in a format similar to that used by 668 Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages). 669 </p> 670 <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for informations systems. It is designed to hide the details of how a service is implemented 671 by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do 672 not need to be aware of each client's purpose: an HTTP request can be considered in isolation rather than being associated 673 with a specific type of client or a predetermined sequence of application steps. The result is a protocol that can be used 674 effectively in many different contexts and for which implementations can evolve independently over time. 675 </p> 676 <p id="rfc.section.1.p.3">HTTP is also designed for use as a generic protocol for translating communication to and from other Internet information systems, 662 677 such as USENET news services via NNTP <a href="#RFC3977" id="rfc.xref.RFC3977.1"><cite title="Network News Transfer Protocol (NNTP)">[RFC3977]</cite></a>, file services via FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[RFC959]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[RFC1436]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[WAIS]</cite></a>. HTTP proxies and gateways provide access to alternative information services by translating their diverse protocols into 663 678 a hypermedia format that can be viewed and manipulated by clients in the same way as HTTP services. 664 679 </p> 665 <p id="rfc.section.1.p.3">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1" and obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. Part 1 defines how clients determine when to use HTTP, the URI schemes specific to HTTP-based resources, overall network 666 operation with transport protocol connection management, and HTTP message framing. Our goal is to define all of the mechanisms 667 necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements 668 for an HTTP message relay or generic message parser. 680 <p id="rfc.section.1.p.4">One consequence of HTTP flexibility is that we cannot define the protocol in terms of how to implement it behind the interface. 681 Instead, we are limited to restricting the syntax of communication, defining the intent of received communication, and the 682 expected behavior of recipients. If the communication is considered in isolation, then successful actions should be reflected 683 in the observable interface provided by servers. However, since many clients are potentially acting in parallel and perhaps 684 at cross-purposes, it would be meaningless to require that such behavior be observable. 685 </p> 686 <p id="rfc.section.1.p.5">This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1" and obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. Part 1 defines the URI schemes specific to HTTP-based resources, overall network operation, transport protocol connection 687 management, and HTTP message framing and forwarding requirements. Our goal is to define all of the mechanisms necessary for 688 HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for a message 689 parser and transparent message-forwarding intermediaries. 669 690 </p> 670 691 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> … … 720 741 </div> 721 742 <p id="rfc.section.1.2.2.p.3">Historically, HTTP/1.1 header field values allow linear white space folding across multiple lines. However, this specification 722 deprecates its use; senders <em class="bcp14">MUST NOT</em> produce messages that include LWS folding (i.e., use the obs-fold rule), except within the message/http media type (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 8.3.1</a>). Receivers <em class="bcp14">SHOULD</em> still parse folded linear white space.743 deprecates its use; senders <em class="bcp14">MUST NOT</em> produce messages that include LWS folding (i.e., use the obs-fold rule), except within the message/http media type (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a>). Receivers <em class="bcp14">SHOULD</em> still parse folded linear white space. 723 744 </p> 724 745 <p id="rfc.section.1.2.2.p.4">This specification uses three rules to denote the use of linear white space; BWS ("Bad" White Space), OWS (Optional White … … 751 772 </p> 752 773 <div id="rule.token.separators"> 753 <p id="rfc.section.1.2.2.p.12"> Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 2.4</a>).774 <p id="rfc.section.1.2.2.p.12"> Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 3.3</a>). 754 775 </p> 755 776 </div> … … 790 811 <a href="#abnf.dependencies" class="smpl">Pragma</a> = <Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a>> 791 812 <a href="#abnf.dependencies" class="smpl">Warning</a> = <Warning, defined in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 16.6</a>> 792 </pre><h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> <a id="intro.overall.operation" href="#intro.overall.operation">Overall Operation</a></h2> 793 <p id="rfc.section.1.3.p.1">HTTP is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol 813 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="architecture" href="#architecture">HTTP architecture</a></h1> 814 <p id="rfc.section.2.p.1">HTTP was created with a specific architecture in mind, the World Wide Web, and has evolved over time to support the scalability 815 needs of a worldwide hypertext system. Much of that architecture is reflected in the terminology and syntax productions used 816 to define HTTP. 817 </p> 818 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="uri" href="#uri">Uniform Resource Identifiers</a></h2> 819 <p id="rfc.section.2.1.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources. URI references are used to target requests, redirect responses, 820 and define relationships. HTTP does not limit what a resource may be; it merely defines an interface that can be used to interact 821 with a resource via HTTP. More information on the scope of URIs and resources can be found in <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>. 822 </p> 823 <p id="rfc.section.2.1.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "fragment", "port", "host", 824 "path-abempty", "path-absolute", "query", and "authority" from <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>. In addition, we define a partial-URI rule for protocol elements that allow a relative URI without a fragment. 825 </p> 826 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span> <a href="#uri" class="smpl">URI</a> = <URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3">Section 3</a>> 827 <a href="#uri" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.6"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>> 828 <a href="#uri" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.7"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>> 829 <a href="#uri" class="smpl">relative-part</a> = <relative-part, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.8"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>> 830 <a href="#uri" class="smpl">authority</a> = <authority, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.9"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2">Section 3.2</a>> 831 <a href="#uri" class="smpl">fragment</a> = <fragment, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.10"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>> 832 <a href="#uri" class="smpl">path-abempty</a> = <path-abempty, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.11"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>> 833 <a href="#uri" class="smpl">path-absolute</a> = <path-absolute, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.12"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>> 834 <a href="#uri" class="smpl">port</a> = <port, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.13"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.3">Section 3.2.3</a>> 835 <a href="#uri" class="smpl">query</a> = <query, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.4">Section 3.4</a>> 836 <a href="#uri" class="smpl">uri-host</a> = <host, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>> 837 838 <a href="#uri" class="smpl">partial-URI</a> = relative-part [ "?" query ] 839 </pre><p id="rfc.section.2.1.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows 840 only a URI in absolute form (absolute-URI), any relative reference (relative-ref), or some other subset of the URI-reference 841 grammar. Unless otherwise indicated, URI references are parsed relative to the request target (the default base URI for both 842 the request and its corresponding response). 843 </p> 844 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <a id="http.uri" href="#http.uri">http URI scheme</a></h3> 845 <div id="rfc.iref.h.1"></div> 846 <div id="rfc.iref.u.1"></div> 847 <p id="rfc.section.2.1.1.p.1">The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the syntax and semantics 848 for identifiers using the http or https URI schemes. 849 </p> 850 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.33"></span> <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 851 </pre><p id="rfc.section.2.1.1.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server 852 listening for TCP connections on that port of that host, and the request-target for the resource is path-absolute (<a href="#request-target" title="request-target">Section 5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the path-absolute is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a request-target for a resource (<a href="#request-target" title="request-target">Section 5.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name. 853 </p> 854 <dl class="empty"> 855 <dd> <span id="rfc.iref.h.2"></span> <span id="rfc.iref.u.2"></span> <b>Note:</b> the "https" scheme is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. 856 </dd> 857 </dl> 858 <h3 id="rfc.section.2.1.2"><a href="#rfc.section.2.1.2">2.1.2</a> <a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3> 859 <p id="rfc.section.2.1.2.p.1">When comparing two URIs to decide if they match or not, a client <em class="bcp14">SHOULD</em> use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: 860 </p> 861 <ul> 862 <li>A port that is empty or not given is equivalent to the default port for that URI-reference;</li> 863 <li>Comparisons of host names <em class="bcp14">MUST</em> be case-insensitive; 864 </li> 865 <li>Comparisons of scheme names <em class="bcp14">MUST</em> be case-insensitive; 866 </li> 867 <li>An empty path-absolute is equivalent to an path-absolute of "/".</li> 868 </ul> 869 <p id="rfc.section.2.1.2.p.2">Characters other than those in the "reserved" set (see <a href="#RFC3986" id="rfc.xref.RFC3986.16"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.2">Section 2.2</a>) are equivalent to their ""%" <a href="#core.rules" class="smpl">HEXDIG</a> <a href="#core.rules" class="smpl">HEXDIG</a>" encoding. 870 </p> 871 <p id="rfc.section.2.1.2.p.3">For example, the following three URIs are equivalent:</p> 872 <div id="rfc.figure.u.14"></div><pre class="text"> http://example.com:80/~smith/home.html 873 http://EXAMPLE.com/%7Esmith/home.html 874 http://EXAMPLE.com:/%7esmith/home.html 875 </pre><h3 id="rfc.section.2.1.3"><a href="#rfc.section.2.1.3">2.1.3</a> <a id="scheme.aliases" href="#scheme.aliases">Scheme aliases considered harmful</a></h3> 876 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="intro.overall.operation" href="#intro.overall.operation">Overall Operation</a></h2> 877 <p id="rfc.section.2.2.p.1">HTTP is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol 794 878 version, followed by a MIME-like message containing request modifiers, client information, and possible body content over 795 879 a connection with a server. The server responds with a status line, including the message's protocol version and a success 796 880 or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body 797 content. The relationship between HTTP and MIME is described in <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.798 </p> 799 <p id="rfc.section. 1.3.p.2">Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin881 content. 882 </p> 883 <p id="rfc.section.2.2.p.2">Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin 800 884 server. In the simplest case, this may be accomplished via a single connection (v) between the user agent (UA) and the origin 801 885 server (O). 802 886 </p> 803 <div id="rfc.figure.u.1 2"></div><pre class="drawing"> request chain ------------------------>887 <div id="rfc.figure.u.15"></div><pre class="drawing"> request chain ------------------------> 804 888 UA -------------------v------------------- O 805 889 <----------------------- response chain 806 </pre><p id="rfc.section. 1.3.p.4">A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three890 </pre><p id="rfc.section.2.2.p.4">A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three 807 891 common forms of intermediary: proxy, gateway, and tunnel. A proxy is a forwarding agent, receiving requests for a URI in its 808 892 absolute form, rewriting all or part of the message, and forwarding the reformatted request toward the server identified by … … 812 896 cannot understand the contents of the messages. 813 897 </p> 814 <div id="rfc.figure.u.1 3"></div><pre class="drawing"> request chain -------------------------------------->898 <div id="rfc.figure.u.16"></div><pre class="drawing"> request chain --------------------------------------> 815 899 UA -----v----- A -----v----- B -----v----- C -----v----- O 816 900 <------------------------------------- response chain 817 </pre><p id="rfc.section. 1.3.p.6">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response901 </pre><p id="rfc.section.2.2.p.6">The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response 818 902 message that travels the whole chain will pass through four separate connections. This distinction is important because some 819 903 HTTP communication options may apply only to the connection with the nearest, non-tunnel neighbor, only to the end-points … … 822 906 to servers other than C, at the same time that it is handling A's request. 823 907 </p> 824 <p id="rfc.section. 1.3.p.7">Any party to the communication which is not acting as a tunnel may employ an internal cache for handling requests. The effect908 <p id="rfc.section.2.2.p.7">Any party to the communication which is not acting as a tunnel may employ an internal cache for handling requests. The effect 825 909 of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response 826 910 applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response from 827 911 O (via C) for a request which has not been cached by UA or A. 828 912 </p> 829 <div id="rfc.figure.u.1 4"></div><pre class="drawing"> request chain ---------->913 <div id="rfc.figure.u.17"></div><pre class="drawing"> request chain ----------> 830 914 UA -----v----- A -----v----- B - - - - - - C - - - - - - O 831 915 <--------- response chain 832 </pre><p id="rfc.section. 1.3.p.9">Not all responses are usefully cacheable, and some requests may contain modifiers which place special requirements on cache916 </pre><p id="rfc.section.2.2.p.9">Not all responses are usefully cacheable, and some requests may contain modifiers which place special requirements on cache 833 917 behavior. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching" title="Introduction">Section 1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 834 918 </p> 835 <p id="rfc.section. 1.3.p.10">In fact, there are a wide variety of architectures and configurations of caches and proxies currently being experimented with919 <p id="rfc.section.2.2.p.10">In fact, there are a wide variety of architectures and configurations of caches and proxies currently being experimented with 836 920 or deployed across the World Wide Web. These systems include national hierarchies of proxy caches to save transoceanic bandwidth, 837 921 systems that broadcast or multicast cache entries, organizations that distribute subsets of cached data via CD-ROM, and so … … 841 925 failing that, at least reliable indications of failure. 842 926 </p> 843 <p id="rfc.section. 1.3.p.11">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 (<<a href="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</a>>), but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet,927 <p id="rfc.section.2.2.p.11">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 (<<a href="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</a>>), but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, 844 928 or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the 845 929 mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside 846 930 the scope of this specification. 847 931 </p> 848 <p id="rfc.section.1.3.p.12">In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may 849 be used for one or more request/response exchanges, although connections may be closed for a variety of reasons (see <a href="#persistent.connections" title="Persistent Connections">Section 6.1</a>). 850 </p> 851 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 852 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="http.version" href="#http.version">HTTP Version</a></h2> 853 <p id="rfc.section.2.1.p.1">HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended 932 <p id="rfc.section.2.2.p.12">In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may 933 be used for one or more request/response exchanges, although connections may be closed for a variety of reasons (see <a href="#persistent.connections" title="Persistent Connections">Section 7.1</a>). 934 </p> 935 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="http.proxy" href="#http.proxy">Use of HTTP for proxy communication</a></h2> 936 <p id="rfc.section.2.3.p.1">Configured to use HTTP to proxy HTTP or other protocols.</p> 937 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="http.intercept" href="#http.intercept">Interception of HTTP for access control</a></h2> 938 <p id="rfc.section.2.4.p.1">Interception of HTTP traffic for initiating access control.</p> 939 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="http.others" href="#http.others">Use of HTTP by other protocols</a></h2> 940 <p id="rfc.section.2.5.p.1">Profiles of HTTP defined by other protocol. Extensions of HTTP like WebDAV.</p> 941 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="http.media" href="#http.media">Use of HTTP by media type specification</a></h2> 942 <p id="rfc.section.2.6.p.1">Instructions on composing HTTP requests via hypertext formats.</p> 943 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 944 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="http.version" href="#http.version">HTTP Version</a></h2> 945 <p id="rfc.section.3.1.p.1">HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended 854 946 to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather 855 947 than the features obtained via that communication. No change is made to the version number for the addition of message components … … 859 951 of a message within the protocol is changed. See <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> for a fuller explanation. 860 952 </p> 861 <p id="rfc.section. 2.1.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p>862 <div id="rfc.figure.u.1 5"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span> <a href="#http.version" class="smpl">HTTP-Version</a> = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" 1*<a href="#core.rules" class="smpl">DIGIT</a> "." 1*<a href="#core.rules" class="smpl">DIGIT</a>953 <p id="rfc.section.3.1.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p> 954 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span> <a href="#http.version" class="smpl">HTTP-Version</a> = <a href="#http.version" class="smpl">HTTP-Prot-Name</a> "/" 1*<a href="#core.rules" class="smpl">DIGIT</a> "." 1*<a href="#core.rules" class="smpl">DIGIT</a> 863 955 <a href="#http.version" class="smpl">HTTP-Prot-Name</a> = %x48.54.54.50 ; "HTTP", case-sensitive 864 </pre><p id="rfc.section. 2.1.p.4">Note that the major and minor numbers <em class="bcp14">MUST</em> be treated as separate integers and that each <em class="bcp14">MAY</em> be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3.956 </pre><p id="rfc.section.3.1.p.4">Note that the major and minor numbers <em class="bcp14">MUST</em> be treated as separate integers and that each <em class="bcp14">MAY</em> be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. 865 957 Leading zeros <em class="bcp14">MUST</em> be ignored by recipients and <em class="bcp14">MUST NOT</em> be sent. 866 958 </p> 867 <p id="rfc.section. 2.1.p.5">An application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" <em class="bcp14">MUST</em> be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this959 <p id="rfc.section.3.1.p.5">An application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" <em class="bcp14">MUST</em> be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this 868 960 specification <em class="bcp14">SHOULD</em> use an HTTP-Version of "HTTP/1.1" in their messages, and <em class="bcp14">MUST</em> do so for any message that is not compatible with HTTP/1.0. For more details on when to send specific HTTP-Version values, 869 961 see <a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. 870 962 </p> 871 <p id="rfc.section. 2.1.p.6">The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.</p>872 <p id="rfc.section. 2.1.p.7">Proxy and gateway applications need to be careful when forwarding messages in protocol versions different from that of the963 <p id="rfc.section.3.1.p.6">The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.</p> 964 <p id="rfc.section.3.1.p.7">Proxy and gateway applications need to be careful when forwarding messages in protocol versions different from that of the 873 965 application. Since the protocol version indicates the protocol capability of the sender, a proxy/gateway <em class="bcp14">MUST NOT</em> send a message with a version indicator which is greater than its actual version. If a higher version request is received, 874 966 the proxy/gateway <em class="bcp14">MUST</em> either downgrade the request version, or respond with an error, or switch to tunnel behavior. 875 967 </p> 876 <p id="rfc.section. 2.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, caching proxies <em class="bcp14">MUST</em>, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request.877 </p> 878 <p id="rfc.section. 2.1.p.9"> </p>968 <p id="rfc.section.3.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, caching proxies <em class="bcp14">MUST</em>, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request. 969 </p> 970 <p id="rfc.section.3.1.p.9"> </p> 879 971 <dl class="empty"> 880 972 <dd> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved. 881 973 </dd> 882 974 </dl> 883 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="uri" href="#uri">Uniform Resource Identifiers</a></h2> 884 <p id="rfc.section.2.2.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used in HTTP to indicate the target of a request and to identify additional resources related to that resource, the request, 885 or the response. Each protocol element in HTTP that allows a URI reference will indicate in its ABNF whether the element allows 886 only a URI in absolute form, any relative reference, or some limited subset of the URI-reference grammar. Unless otherwise 887 indicated, relative URI references are to be parsed relative to the URI corresponding to the request target (the base URI). 888 </p> 889 <p id="rfc.section.2.2.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "fragment", "port", "host", "path-abempty", 890 "path-absolute", "query", and "authority" from <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>: 891 </p> 892 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span> <a href="#uri" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>> 893 <a href="#uri" class="smpl">authority</a> = <authority, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2">Section 3.2</a>> 894 <a href="#uri" class="smpl">fragment</a> = <fragment, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.6"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>> 895 <a href="#uri" class="smpl">path-abempty</a> = <path-abempty, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.7"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>> 896 <a href="#uri" class="smpl">path-absolute</a> = <path-absolute, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.8"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.3">Section 3.3</a>> 897 <a href="#uri" class="smpl">port</a> = <port, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.9"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.3">Section 3.2.3</a>> 898 <a href="#uri" class="smpl">query</a> = <query, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.10"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.4">Section 3.4</a>> 899 <a href="#uri" class="smpl">uri-host</a> = <host, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.11"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>> 900 901 <a href="#uri" class="smpl">relative-part</a> = <relative-part, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.12"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>> 902 <a href="#uri" class="smpl">relativeURI</a> = <a href="#uri" class="smpl">relative-part</a> [ "?" <a href="#uri" class="smpl">query</a> ] 903 </pre><p id="rfc.section.2.2.p.4">HTTP does not place an a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 904 </p> 905 <p id="rfc.section.2.2.p.5"> </p> 906 <dl class="empty"> 907 <dd> <b>Note:</b> Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations 908 might not properly support these lengths. 909 </dd> 910 </dl> 911 <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a> <a id="http.uri" href="#http.uri">http URI scheme</a></h3> 912 <div id="rfc.iref.h.1"></div> 913 <div id="rfc.iref.u.1"></div> 914 <p id="rfc.section.2.2.1.p.1">The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the syntax and semantics 915 for identifiers using the http or https URI schemes. 916 </p> 917 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.37"></span> <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 918 </pre><p id="rfc.section.2.2.1.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server 919 listening for TCP connections on that port of that host, and the Request-URI for the resource is path-absolute (<a href="#request-uri" title="Request-URI">Section 4.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the path-absolute is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource (<a href="#request-uri" title="Request-URI">Section 4.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name. 920 </p> 921 <dl class="empty"> 922 <dd> <span id="rfc.iref.h.2"></span> <span id="rfc.iref.u.2"></span> <b>Note:</b> the "https" scheme is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. 923 </dd> 924 </dl> 925 <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a> <a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3> 926 <p id="rfc.section.2.2.2.p.1">When comparing two URIs to decide if they match or not, a client <em class="bcp14">SHOULD</em> use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: 927 </p> 928 <ul> 929 <li>A port that is empty or not given is equivalent to the default port for that URI-reference;</li> 930 <li>Comparisons of host names <em class="bcp14">MUST</em> be case-insensitive; 931 </li> 932 <li>Comparisons of scheme names <em class="bcp14">MUST</em> be case-insensitive; 933 </li> 934 <li>An empty path-absolute is equivalent to an path-absolute of "/".</li> 935 </ul> 936 <p id="rfc.section.2.2.2.p.2">Characters other than those in the "reserved" set (see <a href="#RFC3986" id="rfc.xref.RFC3986.13"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.2">Section 2.2</a>) are equivalent to their ""%" <a href="#core.rules" class="smpl">HEXDIG</a> <a href="#core.rules" class="smpl">HEXDIG</a>" encoding. 937 </p> 938 <p id="rfc.section.2.2.2.p.3">For example, the following three URIs are equivalent:</p> 939 <div id="rfc.figure.u.18"></div><pre class="text"> http://example.com:80/~smith/home.html 940 http://EXAMPLE.com/%7Esmith/home.html 941 http://EXAMPLE.com:/%7esmith/home.html 942 </pre><h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="date.time.formats" href="#date.time.formats">Date/Time Formats</a></h2> 943 <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a> <a id="full.date" href="#full.date">Full Date</a></h3> 944 <p id="rfc.section.2.3.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p> 975 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="date.time.formats" href="#date.time.formats">Date/Time Formats</a></h2> 976 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="full.date" href="#full.date">Full Date</a></h3> 977 <p id="rfc.section.3.2.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p> 945 978 <div id="rfc.figure.u.19"></div><pre class="text"> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123 946 979 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 947 980 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 948 </pre><p id="rfc.section. 2.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>. The other formats are described here only for compatibility with obsolete implementations. HTTP/1.1 clients and servers981 </pre><p id="rfc.section.3.2.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>. The other formats are described here only for compatibility with obsolete implementations. HTTP/1.1 clients and servers 949 982 that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix A</a> for further information. 950 983 </p> … … 954 987 </dd> 955 988 </dl> 956 <p id="rfc.section. 2.3.1.p.5">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated989 <p id="rfc.section.3.2.1.p.5">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated 957 990 Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for 958 991 time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional LWS beyond that specifically included as SP in the grammar. 959 992 </p> 960 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.3 8"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span> <a href="#full.date" class="smpl">HTTP-date</a> = <a href="#full.date" class="smpl">rfc1123-date</a> / <a href="#full.date" class="smpl">obsolete-date</a>993 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span> <a href="#full.date" class="smpl">HTTP-date</a> = <a href="#full.date" class="smpl">rfc1123-date</a> / <a href="#full.date" class="smpl">obsolete-date</a> 961 994 <a href="#full.date" class="smpl">obsolete-date</a> = <a href="#full.date" class="smpl">rfc850-date</a> / <a href="#full.date" class="smpl">asctime-date</a> 962 995 <a href="#full.date" class="smpl">rfc1123-date</a> = <a href="#full.date" class="smpl">wkday</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> time <a href="#core.rules" class="smpl">SP</a> GMT … … 1009 1042 s-Nov = %x4E.6F.76 ; "Nov", case-sensitive 1010 1043 s-Dec = %x44.65.63 ; "Dec", case-sensitive 1011 </pre><p id="rfc.section. 2.3.1.p.7"> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers1044 </pre><p id="rfc.section.3.2.1.p.7"> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers 1012 1045 are not required to use these formats for user presentation, request logging, etc. 1013 1046 </p> 1014 <h2 id="rfc.section. 2.4"><a href="#rfc.section.2.4">2.4</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2>1015 <p id="rfc.section. 2.4.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to1047 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h2> 1048 <p id="rfc.section.3.3.p.1">Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to 1016 1049 an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer-coding 1017 1050 is a property of the message, not of the original entity. 1018 1051 </p> 1019 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g. 50"></span><span id="rfc.iref.g.51"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" / <a href="#transfer.codings" class="smpl">transfer-extension</a>1052 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span> <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" / <a href="#transfer.codings" class="smpl">transfer-extension</a> 1020 1053 <a href="#transfer.codings" class="smpl">transfer-extension</a> = <a href="#rule.token.separators" class="smpl">token</a> *( <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#transfer.codings" class="smpl">parameter</a> ) 1021 1054 </pre><div id="rule.parameter"> 1022 <p id="rfc.section. 2.4.p.3"> Parameters are in the form of attribute/value pairs.</p>1055 <p id="rfc.section.3.3.p.3"> Parameters are in the form of attribute/value pairs.</p> 1023 1056 </div> 1024 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.5 2"></span><span id="rfc.iref.g.53"></span><span id="rfc.iref.g.54"></span> <a href="#transfer.codings" class="smpl">parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a>1057 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span> <a href="#transfer.codings" class="smpl">parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a> 1025 1058 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1026 1059 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> 1027 </pre><p id="rfc.section. 2.4.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 7.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 7.7</a>).1028 </p> 1029 <p id="rfc.section. 2.4.p.6">Whenever a transfer-coding is applied to a message-body, the set of transfer-codings <em class="bcp14">MUST</em> include "chunked", unless the message indicates it is terminated by closing the connection. When the "chunked" transfer-coding1060 </pre><p id="rfc.section.3.3.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 8.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 8.7</a>). 1061 </p> 1062 <p id="rfc.section.3.3.p.6">Whenever a transfer-coding is applied to a message-body, the set of transfer-codings <em class="bcp14">MUST</em> include "chunked", unless the message indicates it is terminated by closing the connection. When the "chunked" transfer-coding 1030 1063 is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message 1031 (<a href="#message.length" title="Message Length">Section 3.4</a>).1032 </p> 1033 <p id="rfc.section. 2.4.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has1064 (<a href="#message.length" title="Message Length">Section 4.4</a>). 1065 </p> 1066 <p id="rfc.section.3.3.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has 1034 1067 a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic of message-bodies is the difficulty 1035 in determining the exact body length (<a href="#message.length" title="Message Length">Section 3.4</a>), or the desire to encrypt data over a shared transport.1036 </p> 1037 <p id="rfc.section. 2.4.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry1038 contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 2.4.1</a>), "gzip", "compress", and "deflate" (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).1039 </p> 1040 <p id="rfc.section. 2.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).1041 </p> 1042 <p id="rfc.section. 2.4.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Not Implemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.1043 </p> 1044 <h3 id="rfc.section. 2.4.1"><a href="#rfc.section.2.4.1">2.4.1</a> <a id="chunked.transfer.encoding" href="#chunked.transfer.encoding">Chunked Transfer Coding</a></h3>1045 <p id="rfc.section. 2.4.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size1068 in determining the exact body length (<a href="#message.length" title="Message Length">Section 4.4</a>), or the desire to encrypt data over a shared transport. 1069 </p> 1070 <p id="rfc.section.3.3.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry 1071 contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.3.1</a>), "gzip", "compress", and "deflate" (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1072 </p> 1073 <p id="rfc.section.3.3.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="p3-payload.html#content.codings" title="Content Codings">Section 3.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1074 </p> 1075 <p id="rfc.section.3.3.p.10">A server which receives an entity-body with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> return 501 (Not Implemented), and close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client. 1076 </p> 1077 <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="chunked.transfer.encoding" href="#chunked.transfer.encoding">Chunked Transfer Coding</a></h3> 1078 <p id="rfc.section.3.3.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size 1046 1079 indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing entity-header fields. This allows dynamically produced content to be transferred along with the information 1047 1080 necessary for the recipient to verify that it has received the full message. 1048 1081 </p> 1049 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.5 5"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span> <a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.transfer.encoding" class="smpl">chunk</a>1082 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.53"></span><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span> <a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a> = *<a href="#chunked.transfer.encoding" class="smpl">chunk</a> 1050 1083 <a href="#chunked.transfer.encoding" class="smpl">last-chunk</a> 1051 1084 <a href="#chunked.transfer.encoding" class="smpl">trailer-part</a> … … 1063 1096 <a href="#chunked.transfer.encoding" class="smpl">chunk-data</a> = 1*<a href="#core.rules" class="smpl">OCTET</a> ; a sequence of chunk-size octets 1064 1097 <a href="#chunked.transfer.encoding" class="smpl">trailer-part</a> = *(<a href="#abnf.dependencies" class="smpl">entity-header</a> <a href="#core.rules" class="smpl">CRLF</a>) 1065 </pre><p id="rfc.section. 2.4.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended1098 </pre><p id="rfc.section.3.3.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended 1066 1099 by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line. 1067 1100 </p> 1068 <p id="rfc.section. 2.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field1069 can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 7.6</a>).1070 </p> 1071 <p id="rfc.section. 2.4.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true:1101 <p id="rfc.section.3.3.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field 1102 can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 8.6</a>). 1103 </p> 1104 <p id="rfc.section.3.3.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true: 1072 1105 </p> 1073 1106 <ol> 1074 1107 <li>the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as 1075 described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 7.5</a>; or,1108 described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 8.5</a>; or, 1076 1109 </li> 1077 1110 <li>the server is the origin server for the response, the trailer fields consist entirely of optional metadata, and the recipient … … 1080 1113 </li> 1081 1114 </ol> 1082 <p id="rfc.section. 2.4.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and1115 <p id="rfc.section.3.3.1.p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and 1083 1116 forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have necessitated a possibly 1084 1117 infinite buffer on the proxy. 1085 1118 </p> 1086 <p id="rfc.section. 2.4.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>1119 <p id="rfc.section.3.3.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 1087 1120 <div id="rfc.figure.u.24"></div><pre class="text"> length := 0 1088 1121 read chunk-size, chunk-ext (if any) and CRLF … … 1100 1133 Content-Length := length 1101 1134 Remove "chunked" from Transfer-Encoding 1102 </pre><p id="rfc.section. 2.4.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding, and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.1103 </p> 1104 <h2 id="rfc.section. 2.5"><a href="#rfc.section.2.5">2.5</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>1105 <p id="rfc.section. 2.5.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields1135 </pre><p id="rfc.section.3.3.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding, and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand. 1136 </p> 1137 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h2> 1138 <p id="rfc.section.3.4.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields 1106 1139 using product tokens also allow sub-products which form a significant part of the application to be listed, separated by white 1107 1140 space. By convention, the products are listed in order of their significance for identifying the application. 1108 1141 </p> 1109 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.6 4"></span><span id="rfc.iref.g.65"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>]1142 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span> <a href="#product.tokens" class="smpl">product</a> = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] 1110 1143 <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 1111 </pre><p id="rfc.section. 2.5.p.3">Examples:</p>1144 </pre><p id="rfc.section.3.4.p.3">Examples:</p> 1112 1145 <div id="rfc.figure.u.26"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1113 1146 Server: Apache/0.8.4 1114 </pre><p id="rfc.section. 2.5.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token character <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value).1115 </p> 1116 <h1 id="rfc.section. 3"><a href="#rfc.section.3">3.</a> <a id="http.message" href="#http.message">HTTP Message</a></h1>1117 <h2 id="rfc.section. 3.1"><a href="#rfc.section.3.1">3.1</a> <a id="message.types" href="#message.types">Message Types</a></h2>1118 <p id="rfc.section. 3.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p>1119 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.6 6"></span> <a href="#message.types" class="smpl">HTTP-message</a> = <a href="#request" class="smpl">Request</a> / <a href="#response" class="smpl">Response</a> ; HTTP/1.1 messages1120 </pre><p id="rfc.section. 3.1.p.3">Request (<a href="#request" title="Request">Section 4</a>) and Response (<a href="#response" title="Response">Section 5</a>) messages use the generic message format of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header1147 </pre><p id="rfc.section.3.4.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token character <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value). 1148 </p> 1149 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="http.message" href="#http.message">HTTP Message</a></h1> 1150 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="message.types" href="#message.types">Message Types</a></h2> 1151 <p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p> 1152 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.64"></span> <a href="#message.types" class="smpl">HTTP-message</a> = <a href="#request" class="smpl">Request</a> / <a href="#response" class="smpl">Response</a> ; HTTP/1.1 messages 1153 </pre><p id="rfc.section.4.1.p.3">Request (<a href="#request" title="Request">Section 5</a>) and Response (<a href="#response" title="Response">Section 6</a>) messages use the generic message format of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header 1121 1154 fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header 1122 1155 fields, and possibly a message-body. 1123 1156 </p> 1124 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.6 7"></span><span id="rfc.iref.g.68"></span> <a href="#message.types" class="smpl">generic-message</a> = <a href="#message.types" class="smpl">start-line</a>1157 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span> <a href="#message.types" class="smpl">generic-message</a> = <a href="#message.types" class="smpl">start-line</a> 1125 1158 *(<a href="#message.headers" class="smpl">message-header</a> <a href="#core.rules" class="smpl">CRLF</a>) 1126 1159 <a href="#core.rules" class="smpl">CRLF</a> 1127 1160 [ <a href="#message.body" class="smpl">message-body</a> ] 1128 1161 <a href="#message.types" class="smpl">start-line</a> = <a href="#request-line" class="smpl">Request-Line</a> / <a href="#status-line" class="smpl">Status-Line</a> 1129 </pre><p id="rfc.section. 3.1.p.5">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol1162 </pre><p id="rfc.section.4.1.p.5">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol 1130 1163 stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF. 1131 1164 </p> 1132 <p id="rfc.section. 3.1.p.6">Certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly forbidden1165 <p id="rfc.section.4.1.p.6">Certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly forbidden 1133 1166 by the BNF, an HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. 1134 1167 </p> 1135 <h2 id="rfc.section. 3.2"><a href="#rfc.section.3.2">3.2</a> <a id="message.headers" href="#message.headers">Message Headers</a></h2>1136 <p id="rfc.section. 3.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 3.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc5322#section-2.1">Section 2.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The1168 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="message.headers" href="#message.headers">Message Headers</a></h2> 1169 <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc5322#section-2.1">Section 2.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The 1137 1170 field value <em class="bcp14">MAY</em> be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding 1138 1171 each extra line with at least one SP or HTAB. Applications ought to follow "common form", where one is known or indicated, … … 1140 1173 forms. 1141 1174 </p> 1142 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.6 9"></span><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span> <a href="#message.headers" class="smpl">message-header</a> = <a href="#message.headers" class="smpl">field-name</a> ":" [ <a href="#message.headers" class="smpl">field-value</a> ]1175 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span> <a href="#message.headers" class="smpl">message-header</a> = <a href="#message.headers" class="smpl">field-name</a> ":" [ <a href="#message.headers" class="smpl">field-value</a> ] 1143 1176 <a href="#message.headers" class="smpl">field-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1144 1177 <a href="#message.headers" class="smpl">field-value</a> = *( <a href="#message.headers" class="smpl">field-content</a> / <a href="#rule.whitespace" class="smpl">OWS</a> ) 1145 1178 <a href="#message.headers" class="smpl">field-content</a> = <field content> 1146 </pre><p id="rfc.section. 3.2.p.3"> <span class="comment">[rfc.comment.1: whitespace between field-name and colon is an error and MUST NOT be accepted]</span>1147 </p> 1148 <p id="rfc.section. 3.2.p.4">The field-content does not include any leading or trailing LWS: linear white space occurring before the first non-whitespace1179 </pre><p id="rfc.section.4.2.p.3"> <span class="comment">[rfc.comment.1: whitespace between field-name and colon is an error and MUST NOT be accepted]</span> 1180 </p> 1181 <p id="rfc.section.4.2.p.4">The field-content does not include any leading or trailing LWS: linear white space occurring before the first non-whitespace 1149 1182 character of the field-value or after the last non-whitespace character of the field-value. Such leading or trailing LWS <em class="bcp14">MAY</em> be removed without changing the semantics of the field value. Any LWS that occurs between field-content <em class="bcp14">MAY</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream. 1150 1183 </p> 1151 <p id="rfc.section. 3.2.p.5">The order in which header fields with differing field names are received is not significant. However, it is "good practice"1184 <p id="rfc.section.4.2.p.5">The order in which header fields with differing field names are received is not significant. However, it is "good practice" 1152 1185 to send general-header fields first, followed by request-header or response-header fields, and ending with the entity-header 1153 1186 fields. 1154 1187 </p> 1155 <p id="rfc.section. 3.2.p.6">Multiple message-header fields with the same field-name <em class="bcp14">MAY</em> be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e.,1188 <p id="rfc.section.4.2.p.6">Multiple message-header fields with the same field-name <em class="bcp14">MAY</em> be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., 1156 1189 #(values)]. It <em class="bcp14">MUST</em> be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics 1157 1190 of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header … … 1159 1192 thus a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when a message is forwarded. 1160 1193 </p> 1161 <p id="rfc.section. 3.2.p.7"> </p>1194 <p id="rfc.section.4.2.p.7"> </p> 1162 1195 <dl class="empty"> 1163 1196 <dd> <b>Note:</b> the "Set-Cookie" header as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix … … 1165 1198 </dd> 1166 1199 </dl> 1167 <h2 id="rfc.section. 3.3"><a href="#rfc.section.3.3">3.3</a> <a id="message.body" href="#message.body">Message Body</a></h2>1168 <p id="rfc.section. 3.3.p.1">The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The1200 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="message.body" href="#message.body">Message Body</a></h2> 1201 <p id="rfc.section.4.3.p.1">The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The 1169 1202 message-body differs from the entity-body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding 1170 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 7.7</a>).1171 </p> 1172 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.7 3"></span> <a href="#message.body" class="smpl">message-body</a> = <a href="#abnf.dependencies" class="smpl">entity-body</a>1203 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 8.7</a>). 1204 </p> 1205 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.71"></span> <a href="#message.body" class="smpl">message-body</a> = <a href="#abnf.dependencies" class="smpl">entity-body</a> 1173 1206 / <entity-body encoded as per <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>> 1174 </pre><p id="rfc.section. 3.3.p.3">Transfer-Encoding <em class="bcp14">MUST</em> be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding1175 is a property of the message, not of the entity, and thus <em class="bcp14">MAY</em> be added or removed by any application along the request/response chain. (However, <a href="#transfer.codings" title="Transfer Codings">Section 2.4</a> places restrictions on when certain transfer-codings may be used.)1176 </p> 1177 <p id="rfc.section. 3.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p>1178 <p id="rfc.section. 3.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field1179 in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2. 6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length1207 </pre><p id="rfc.section.4.3.p.3">Transfer-Encoding <em class="bcp14">MUST</em> be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding 1208 is a property of the message, not of the entity, and thus <em class="bcp14">MAY</em> be added or removed by any application along the request/response chain. (However, <a href="#transfer.codings" title="Transfer Codings">Section 3.3</a> places restrictions on when certain transfer-codings may be used.) 1209 </p> 1210 <p id="rfc.section.4.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p> 1211 <p id="rfc.section.4.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field 1212 in the request's message-headers. A message-body <em class="bcp14">MUST NOT</em> be included in a request if the specification of the request method (<a href="p2-semantics.html#method" title="Method">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) explicitly disallows an entity-body in requests. When a request message contains both a message-body of non-zero length 1180 1213 and a method that does not define any semantics for that request message-body, then an origin server <em class="bcp14">SHOULD</em> either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented 1181 1214 the same request, <em class="bcp14">SHOULD</em> either forward the request inbound with the message-body or ignore the message-body when determining a response. 1182 1215 </p> 1183 <p id="rfc.section. 3.3.p.6">For response messages, whether or not a message-body is included with a message is dependent on both the request method and1184 the response status code (<a href="#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 5.1.1</a>). All responses to the HEAD request method <em class="bcp14">MUST NOT</em> include a message-body, even though the presence of entity-header fields might lead one to believe they do. All 1xx (informational),1216 <p id="rfc.section.4.3.p.6">For response messages, whether or not a message-body is included with a message is dependent on both the request method and 1217 the response status code (<a href="#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 6.1.1</a>). All responses to the HEAD request method <em class="bcp14">MUST NOT</em> include a message-body, even though the presence of entity-header fields might lead one to believe they do. All 1xx (informational), 1185 1218 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although it <em class="bcp14">MAY</em> be of zero length. 1186 1219 </p> 1187 <h2 id="rfc.section. 3.4"><a href="#rfc.section.3.4">3.4</a> <a id="message.length" href="#message.length">Message Length</a></h2>1188 <p id="rfc.section. 3.4.p.1">The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings1220 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="message.length" href="#message.length">Message Length</a></h2> 1221 <p id="rfc.section.4.4.p.1">The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings 1189 1222 have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of 1190 1223 the following (in order of precedence): 1191 1224 </p> 1192 <p id="rfc.section. 3.4.p.2"> </p>1225 <p id="rfc.section.4.4.p.2"> </p> 1193 1226 <ol> 1194 1227 <li> … … 1198 1231 </li> 1199 1232 <li> 1200 <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 7.7</a>) is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 2.4</a>) is used, the transfer-length is defined by the use of this transfer-coding. If a Transfer-Encoding header field is present1233 <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 8.7</a>) is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 3.3</a>) is used, the transfer-length is defined by the use of this transfer-coding. If a Transfer-Encoding header field is present 1201 1234 and the "chunked" transfer-coding is not present, the transfer-length is defined by the sender closing the connection. 1202 1235 </p> 1203 1236 </li> 1204 1237 <li> 1205 <p>If a Content-Length header field (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 7.2</a>) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header1238 <p>If a Content-Length header field (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 8.2</a>) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header 1206 1239 field <em class="bcp14">MUST NOT</em> be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received 1207 1240 with both a Transfer-Encoding header field and a Content-Length header field, the latter <em class="bcp14">MUST</em> be ignored. … … 1224 1257 </li> 1225 1258 </ol> 1226 <p id="rfc.section. 3.4.p.3">For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body1259 <p id="rfc.section.4.4.p.3">For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body 1227 1260 and a Content-Length is not given, the server <em class="bcp14">SHOULD</em> respond with 400 (Bad Request) if it cannot determine the length of the message, or with 411 (Length Required) if it wishes 1228 1261 to insist on receiving a valid Content-Length. 1229 1262 </p> 1230 <p id="rfc.section. 3.4.p.4">All HTTP/1.1 applications that receive entities <em class="bcp14">MUST</em> accept the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 2.4</a>), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.1231 </p> 1232 <p id="rfc.section. 3.4.p.5">Messages <em class="bcp14">MUST NOT</em> include both a Content-Length header field and a transfer-coding. If the message does include a transfer-coding, the Content-Length <em class="bcp14">MUST</em> be ignored.1233 </p> 1234 <p id="rfc.section. 3.4.p.6">When a Content-Length is given in a message where a message-body is allowed, its field value <em class="bcp14">MUST</em> exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents <em class="bcp14">MUST</em> notify the user when an invalid length is received and detected.1235 </p> 1236 <h2 id="rfc.section. 3.5"><a href="#rfc.section.3.5">3.5</a> <a id="general.header.fields" href="#general.header.fields">General Header Fields</a></h2>1237 <p id="rfc.section. 3.5.p.1">There are a few header fields which have general applicability for both request and response messages, but which do not apply1263 <p id="rfc.section.4.4.p.4">All HTTP/1.1 applications that receive entities <em class="bcp14">MUST</em> accept the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 3.3</a>), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance. 1264 </p> 1265 <p id="rfc.section.4.4.p.5">Messages <em class="bcp14">MUST NOT</em> include both a Content-Length header field and a transfer-coding. If the message does include a transfer-coding, the Content-Length <em class="bcp14">MUST</em> be ignored. 1266 </p> 1267 <p id="rfc.section.4.4.p.6">When a Content-Length is given in a message where a message-body is allowed, its field value <em class="bcp14">MUST</em> exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents <em class="bcp14">MUST</em> notify the user when an invalid length is received and detected. 1268 </p> 1269 <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a> <a id="general.header.fields" href="#general.header.fields">General Header Fields</a></h2> 1270 <p id="rfc.section.4.5.p.1">There are a few header fields which have general applicability for both request and response messages, but which do not apply 1238 1271 to the entity being transferred. These header fields apply only to the message being transmitted. 1239 1272 </p> 1240 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.7 4"></span> <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a> ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 16.2</a>1241 / <a href="#header.connection" class="smpl">Connection</a> ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 7.1</a>1242 / <a href="#header.date" class="smpl">Date</a> ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 7.3</a>1273 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.72"></span> <a href="#general.header.fields" class="smpl">general-header</a> = <a href="#abnf.dependencies" class="smpl">Cache-Control</a> ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 16.2</a> 1274 / <a href="#header.connection" class="smpl">Connection</a> ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section 8.1</a> 1275 / <a href="#header.date" class="smpl">Date</a> ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 8.3</a> 1243 1276 / <a href="#abnf.dependencies" class="smpl">Pragma</a> ; <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 16.4</a> 1244 / <a href="#header.trailer" class="smpl">Trailer</a> ; <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 7.6</a>1245 / <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 7.7</a>1246 / <a href="#header.upgrade" class="smpl">Upgrade</a> ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 7.8</a>1247 / <a href="#header.via" class="smpl">Via</a> ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 7.9</a>1277 / <a href="#header.trailer" class="smpl">Trailer</a> ; <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 8.6</a> 1278 / <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 8.7</a> 1279 / <a href="#header.upgrade" class="smpl">Upgrade</a> ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 8.8</a> 1280 / <a href="#header.via" class="smpl">Via</a> ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 8.9</a> 1248 1281 / <a href="#abnf.dependencies" class="smpl">Warning</a> ; <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 16.6</a> 1249 </pre><p id="rfc.section. 3.5.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new1282 </pre><p id="rfc.section.4.5.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new 1250 1283 or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize 1251 1284 them to be general-header fields. Unrecognized header fields are treated as entity-header fields. 1252 1285 </p> 1253 <h1 id="rfc.section. 4"><a href="#rfc.section.4">4.</a> <a id="request" href="#request">Request</a></h1>1254 <p id="rfc.section. 4.p.1">A request message from a client to a server includes, within the first line of that message, the method to be applied to the1286 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="request" href="#request">Request</a></h1> 1287 <p id="rfc.section.5.p.1">A request message from a client to a server includes, within the first line of that message, the method to be applied to the 1255 1288 resource, the identifier of the resource, and the protocol version in use. 1256 1289 </p> 1257 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.7 5"></span> <a href="#request" class="smpl">Request</a> = <a href="#request-line" class="smpl">Request-Line</a> ; <a href="#request-line" title="Request-Line">Section 4.1</a>1258 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 3.5</a>1259 / <a href="#abnf.dependencies" class="smpl">request-header</a> ; <a href="#Part2" id="rfc.xref.Part2. 7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>1260 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>) ; <a href="#Part3" id="rfc.xref.Part3. 10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>1290 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.73"></span> <a href="#request" class="smpl">Request</a> = <a href="#request-line" class="smpl">Request-Line</a> ; <a href="#request-line" title="Request-Line">Section 5.1</a> 1291 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1292 / <a href="#abnf.dependencies" class="smpl">request-header</a> ; <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> 1293 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>) ; <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> 1261 1294 <a href="#core.rules" class="smpl">CRLF</a> 1262 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 3.3</a>1263 </pre><h2 id="rfc.section. 4.1"><a href="#rfc.section.4.1">4.1</a> <a id="request-line" href="#request-line">Request-Line</a></h2>1264 <p id="rfc.section. 4.1.p.1">The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The1265 elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.1266 </p> 1267 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.7 6"></span> <a href="#request-line" class="smpl">Request-Line</a> = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-uri" class="smpl">Request-URI</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a>1268 </pre><h3 id="rfc.section. 4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a> <a id="method" href="#method">Method</a></h3>1269 <p id="rfc.section. 4.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p>1270 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.7 7"></span><span id="rfc.iref.g.78"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a>1271 </pre><h3 id="rfc.section. 4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="request-uri" href="#request-uri">Request-URI</a></h3>1272 <p id="rfc.section. 4.1.2.p.1">The Request-URI is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section 2.2</a>) and identifies the resource upon which to apply the request.1273 </p> 1274 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.7 9"></span> <a href="#request-uri" class="smpl">Request-URI</a> = "*"1295 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 4.3</a> 1296 </pre><h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="request-line" href="#request-line">Request-Line</a></h2> 1297 <p id="rfc.section.5.1.p.1">The Request-Line begins with a method token, followed by the request-target and the protocol version, and ending with CRLF. 1298 The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. 1299 </p> 1300 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.74"></span> <a href="#request-line" class="smpl">Request-Line</a> = <a href="#method" class="smpl">Method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">CRLF</a> 1301 </pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="method" href="#method">Method</a></h3> 1302 <p id="rfc.section.5.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. The method is case-sensitive.</p> 1303 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1304 </pre><h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a> <a id="request-target" href="#request-target">request-target</a></h3> 1305 <p id="rfc.section.5.1.2.p.1">The request-target is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section 2.1</a>) and identifies the resource upon which to apply the request. 1306 </p> 1307 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.77"></span> <a href="#request-target" class="smpl">request-target</a> = "*" 1275 1308 / <a href="#uri" class="smpl">absolute-URI</a> 1276 1309 / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] ) 1277 1310 / <a href="#uri" class="smpl">authority</a> 1278 </pre><p id="rfc.section. 4.1.2.p.3">The four options for Request-URIare dependent on the nature of the request. The asterisk "*" means that the request does1311 </pre><p id="rfc.section.5.1.2.p.3">The four options for request-target are dependent on the nature of the request. The asterisk "*" means that the request does 1279 1312 not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily 1280 1313 apply to a resource. One example would be 1281 1314 </p> 1282 1315 <div id="rfc.figure.u.36"></div><pre class="text"> OPTIONS * HTTP/1.1 1283 </pre><p id="rfc.section. 4.1.2.p.5">The absolute-URI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,1316 </pre><p id="rfc.section.5.1.2.p.5">The absolute-URI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache, 1284 1317 and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request 1285 1318 loops, a proxy <em class="bcp14">MUST</em> be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example … … 1287 1320 </p> 1288 1321 <div id="rfc.figure.u.37"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1289 </pre><p id="rfc.section. 4.1.2.p.7">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.1290 </p> 1291 <p id="rfc.section. 4.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1292 </p> 1293 <p id="rfc.section. 4.1.2.p.9">The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute1294 path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#http.uri" title="http URI scheme">Section 2.2.1</a>, path-absolute) as the Request-URI, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin1322 </pre><p id="rfc.section.5.1.2.p.7">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. 1323 </p> 1324 <p id="rfc.section.5.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 8.9</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1325 </p> 1326 <p id="rfc.section.5.1.2.p.9">The most common form of request-target is that used to identify a resource on an origin server or gateway. In this case the 1327 absolute path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#http.uri" title="http URI scheme">Section 2.1.1</a>, path-absolute) as the request-target, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin 1295 1328 server would create a TCP connection to port 80 of the host "www.example.org" and send the lines: 1296 1329 </p> 1297 1330 <div id="rfc.figure.u.38"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.1 1298 1331 Host: www.example.org 1299 </pre><p id="rfc.section. 4.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original1332 </pre><p id="rfc.section.5.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original 1300 1333 URI, it <em class="bcp14">MUST</em> be given as "/" (the server root). 1301 1334 </p> 1302 <p id="rfc.section. 4.1.2.p.12">The Request-URI is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section 2.2.1</a>. If the Request-URI is encoded using the "% <a href="#core.rules" class="smpl">HEXDIG</a> <a href="#core.rules" class="smpl">HEXDIG</a>" encoding (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.4">Section 2.4</a>), the origin server <em class="bcp14">MUST</em> decode the Request-URI in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid Request-URIs with an appropriate status code.1303 </p> 1304 <p id="rfc.section. 4.1.2.p.13">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received Request-URIwhen forwarding it to the next inbound server, except as noted1335 <p id="rfc.section.5.1.2.p.12">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section 2.1.1</a>. If the request-target is encoded using the "% <a href="#core.rules" class="smpl">HEXDIG</a> <a href="#core.rules" class="smpl">HEXDIG</a>" encoding (<a href="#RFC3986" id="rfc.xref.RFC3986.17"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.4">Section 2.4</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code. 1336 </p> 1337 <p id="rfc.section.5.1.2.p.13">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received request-target when forwarding it to the next inbound server, except as noted 1305 1338 above to replace a null path-absolute with "/". 1306 1339 </p> 1307 <p id="rfc.section. 4.1.2.p.14"> </p>1340 <p id="rfc.section.5.1.2.p.14"> </p> 1308 1341 <dl class="empty"> 1309 1342 <dd> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using 1310 1343 a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been 1311 known to rewrite the Request-URI.1344 known to rewrite the request-target. 1312 1345 </dd> 1313 1346 </dl> 1314 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2> 1315 <p id="rfc.section.4.2.p.1">The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.</p> 1316 <p id="rfc.section.4.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">Appendix B.1.1</a> for other requirements on Host support in HTTP/1.1.) 1317 </p> 1318 <p id="rfc.section.4.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or 1347 <p id="rfc.section.5.1.2.p.15">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI too long) status if the received request-target 1348 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1349 </p> 1350 <p id="rfc.section.5.1.2.p.16">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more OCTETs. 1351 </p> 1352 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2> 1353 <p id="rfc.section.5.2.p.1">The exact resource identified by an Internet request is determined by examining both the request-target and the Host header 1354 field. 1355 </p> 1356 <p id="rfc.section.5.2.p.2">An origin server that does not allow resources to differ by the requested host <em class="bcp14">MAY</em> ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">Appendix B.1.1</a> for other requirements on Host support in HTTP/1.1.) 1357 </p> 1358 <p id="rfc.section.5.2.p.3">An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or 1319 1359 vanity host names) <em class="bcp14">MUST</em> use the following rules for determining the requested resource on an HTTP/1.1 request: 1320 1360 </p> 1321 1361 <ol> 1322 <li>If Request-URI is an absolute-URI, the host is part of the Request-URI. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored.1323 </li> 1324 <li>If the Request-URI is not an absolute-URI, and the request includes a Host header field, the host is determined by the Host1325 header field value.1362 <li>If request-target is an absolute-URI, the host is part of the request-target. Any Host header field value in the request <em class="bcp14">MUST</em> be ignored. 1363 </li> 1364 <li>If the request-target is not an absolute-URI, and the request includes a Host header field, the host is determined by the 1365 Host header field value. 1326 1366 </li> 1327 1367 <li>If the host as determined by rule 1 or 2 is not a valid host on the server, the response <em class="bcp14">MUST</em> be a 400 (Bad Request) error message. 1328 1368 </li> 1329 1369 </ol> 1330 <p id="rfc.section. 4.2.p.4">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine1370 <p id="rfc.section.5.2.p.4">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine 1331 1371 what exact resource is being requested. 1332 1372 </p> 1333 <h1 id="rfc.section. 5"><a href="#rfc.section.5">5.</a> <a id="response" href="#response">Response</a></h1>1334 <p id="rfc.section. 5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>1335 <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g. 80"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 5.1</a>1336 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 3.5</a>1373 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="response" href="#response">Response</a></h1> 1374 <p id="rfc.section.6.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 1375 <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.78"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 6.1</a> 1376 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1337 1377 / <a href="#abnf.dependencies" class="smpl">response-header</a> ; <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> 1338 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>) ; <a href="#Part3" id="rfc.xref.Part3.1 1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a>1378 / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a>) ; <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 4.1</a> 1339 1379 <a href="#core.rules" class="smpl">CRLF</a> 1340 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 3.3</a>1341 </pre><h2 id="rfc.section. 5.1"><a href="#rfc.section.5.1">5.1</a> <a id="status-line" href="#status-line">Status-Line</a></h2>1342 <p id="rfc.section. 5.1.p.1">The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code1380 [ <a href="#message.body" class="smpl">message-body</a> ] ; <a href="#message.body" title="Message Body">Section 4.3</a> 1381 </pre><h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="status-line" href="#status-line">Status-Line</a></h2> 1382 <p id="rfc.section.6.1.p.1">The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code 1343 1383 and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final 1344 1384 CRLF sequence. 1345 1385 </p> 1346 <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g. 81"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>1347 </pre><h3 id="rfc.section. 5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>1348 <p id="rfc.section. 5.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes1386 <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.79"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1387 </pre><h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3> 1388 <p id="rfc.section.6.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes 1349 1389 are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 9</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code, 1350 1390 out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A 1351 1391 client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase. 1352 1392 </p> 1353 <p id="rfc.section. 5.1.1.p.2">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role.1393 <p id="rfc.section.6.1.1.p.2">The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. 1354 1394 There are 5 values for the first digit: 1355 1395 </p> … … 1361 1401 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1362 1402 </ul> 1363 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.8 2"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a>1403 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1364 1404 <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *<<a href="#rule.TEXT" class="smpl">TEXT</a>, excluding <a href="#core.rules" class="smpl">CR</a>, <a href="#core.rules" class="smpl">LF</a>> 1365 </pre><h1 id="rfc.section. 6"><a href="#rfc.section.6">6.</a> <a id="connections" href="#connections">Connections</a></h1>1366 <h2 id="rfc.section. 6.1"><a href="#rfc.section.6.1">6.1</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>1367 <h3 id="rfc.section. 6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3>1368 <p id="rfc.section. 6.1.1.p.1">Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP1405 </pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="connections" href="#connections">Connections</a></h1> 1406 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2> 1407 <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3> 1408 <p id="rfc.section.7.1.1.p.1">Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP 1369 1409 servers and causing congestion on the Internet. The use of inline images and other associated data often require a client 1370 1410 to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results 1371 1411 from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 (<cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2068.2">RFC 2068</cite>) implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>. 1372 1412 </p> 1373 <p id="rfc.section. 6.1.1.p.2">Persistent HTTP connections have a number of advantages: </p>1413 <p id="rfc.section.7.1.1.p.2">Persistent HTTP connections have a number of advantages: </p> 1374 1414 <ul> 1375 1415 <li>By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, … … 1388 1428 </li> 1389 1429 </ul> 1390 <p id="rfc.section. 6.1.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections.1391 </p> 1392 <h3 id="rfc.section. 6.1.2"><a href="#rfc.section.6.1.2">6.1.2</a> <a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3>1393 <p id="rfc.section. 6.1.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior1430 <p id="rfc.section.7.1.1.p.3">HTTP implementations <em class="bcp14">SHOULD</em> implement persistent connections. 1431 </p> 1432 <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="persistent.overall" href="#persistent.overall">Overall Operation</a></h3> 1433 <p id="rfc.section.7.1.2.p.1">A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior 1394 1434 of any HTTP connection. That is, unless otherwise indicated, the client <em class="bcp14">SHOULD</em> assume that the server will maintain a persistent connection, even after error responses from the server. 1395 1435 </p> 1396 <p id="rfc.section. 6.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling1397 takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 7.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection.1398 </p> 1399 <h4 id="rfc.section. 6.1.2.1"><a href="#rfc.section.6.1.2.1">6.1.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>1400 <p id="rfc.section. 6.1.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header including the connection-token1436 <p id="rfc.section.7.1.2.p.2">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling 1437 takes place using the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 8.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. 1438 </p> 1439 <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4> 1440 <p id="rfc.section.7.1.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header including the connection-token 1401 1441 "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header including the connection-token close. 1402 1442 </p> 1403 <p id="rfc.section. 6.1.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains1443 <p id="rfc.section.7.1.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains 1404 1444 a Connection header with the connection-token close. In case the client does not want to maintain a connection for more than 1405 1445 that request, it <em class="bcp14">SHOULD</em> send a Connection header including the connection-token close. 1406 1446 </p> 1407 <p id="rfc.section. 6.1.2.1.p.3">If either the client or the server sends the close token in the Connection header, that request becomes the last one for the1447 <p id="rfc.section.7.1.2.1.p.3">If either the client or the server sends the close token in the Connection header, that request becomes the last one for the 1408 1448 connection. 1409 1449 </p> 1410 <p id="rfc.section. 6.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix B.2</a> for more information on backward compatibility with HTTP/1.0 clients.1411 </p> 1412 <p id="rfc.section. 6.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.length" title="Message Length">Section 3.4</a>.1413 </p> 1414 <h4 id="rfc.section. 6.1.2.2"><a href="#rfc.section.6.1.2.2">6.1.2.2</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4>1415 <p id="rfc.section. 6.1.2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.1416 </p> 1417 <p id="rfc.section. 6.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.1418 </p> 1419 <p id="rfc.section. 6.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to1450 <p id="rfc.section.7.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix B.2</a> for more information on backward compatibility with HTTP/1.0 clients. 1451 </p> 1452 <p id="rfc.section.7.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.length" title="Message Length">Section 4.4</a>. 1453 </p> 1454 <h4 id="rfc.section.7.1.2.2"><a href="#rfc.section.7.1.2.2">7.1.2.2</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4> 1455 <p id="rfc.section.7.1.2.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received. 1456 </p> 1457 <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 1458 </p> 1459 <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 1420 1460 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status for the previous request. 1421 1461 </p> 1422 <h3 id="rfc.section. 6.1.3"><a href="#rfc.section.6.1.3">6.1.3</a> <a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3>1423 <p id="rfc.section. 6.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 7.1</a>.1424 </p> 1425 <p id="rfc.section. 6.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects1462 <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a> <a id="persistent.proxy" href="#persistent.proxy">Proxy Servers</a></h3> 1463 <p id="rfc.section.7.1.3.p.1">It is especially important that proxies correctly implement the properties of the Connection header field as specified in <a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 8.1</a>. 1464 </p> 1465 <p id="rfc.section.7.1.3.p.2">The proxy server <em class="bcp14">MUST</em> signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects 1426 1466 to. Each persistent connection applies to only one transport link. 1427 1467 </p> 1428 <p id="rfc.section. 6.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).1429 </p> 1430 <h3 id="rfc.section. 6.1.4"><a href="#rfc.section.6.1.4">6.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>1431 <p id="rfc.section. 6.1.4.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers1468 <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients). 1469 </p> 1470 <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> 1471 <p id="rfc.section.7.1.4.p.1">Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers 1432 1472 might make this a higher value since it is likely that the client will be making more connections through the same server. 1433 1473 The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client 1434 1474 or the server. 1435 1475 </p> 1436 <p id="rfc.section. 6.1.4.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does1476 <p id="rfc.section.7.1.4.p.2">When a client or server wishes to time-out it <em class="bcp14">SHOULD</em> issue a graceful close on the transport connection. Clients and servers <em class="bcp14">SHOULD</em> both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does 1437 1477 not detect the other side's close promptly it could cause unnecessary resource drain on the network. 1438 1478 </p> 1439 <p id="rfc.section. 6.1.4.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time1479 <p id="rfc.section.7.1.4.p.3">A client, server, or proxy <em class="bcp14">MAY</em> close the transport connection at any time. For example, a client might have started to send a new request at the same time 1440 1480 that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed 1441 1481 while it was idle, but from the client's point of view, a request is in progress. 1442 1482 </p> 1443 <p id="rfc.section. 6.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request1483 <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 1444 1484 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 8.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 1445 1485 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 1446 1486 </p> 1447 <p id="rfc.section. 6.1.4.p.5">Servers <em class="bcp14">SHOULD</em> always respond to at least one request per connection, if at all possible. Servers <em class="bcp14">SHOULD NOT</em> close a connection in the middle of transmitting a response, unless a network or client failure is suspected.1448 </p> 1449 <p id="rfc.section. 6.1.4.p.6">Clients that use persistent connections <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server. A single-user client <em class="bcp14">SHOULD NOT</em> maintain more than 2 connections with any server or proxy. A proxy <em class="bcp14">SHOULD</em> use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines1487 <p id="rfc.section.7.1.4.p.5">Servers <em class="bcp14">SHOULD</em> always respond to at least one request per connection, if at all possible. Servers <em class="bcp14">SHOULD NOT</em> close a connection in the middle of transmitting a response, unless a network or client failure is suspected. 1488 </p> 1489 <p id="rfc.section.7.1.4.p.6">Clients that use persistent connections <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server. A single-user client <em class="bcp14">SHOULD NOT</em> maintain more than 2 connections with any server or proxy. A proxy <em class="bcp14">SHOULD</em> use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines 1450 1490 are intended to improve HTTP response times and avoid congestion. 1451 1491 </p> 1452 <h2 id="rfc.section. 6.2"><a href="#rfc.section.6.2">6.2</a> <a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2>1453 <h3 id="rfc.section. 6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a> <a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3>1454 <p id="rfc.section. 6.2.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating1492 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="message.transmission.requirements" href="#message.transmission.requirements">Message Transmission Requirements</a></h2> 1493 <h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a> <a id="persistent.flow" href="#persistent.flow">Persistent Connections and Flow Control</a></h3> 1494 <p id="rfc.section.7.2.1.p.1">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating 1455 1495 connections with the expectation that clients will retry. The latter technique can exacerbate network congestion. 1456 1496 </p> 1457 <h3 id="rfc.section. 6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>1458 <p id="rfc.section. 6.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status while it is transmitting the request. If the client sees an error status,1459 it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section 2.4</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client <em class="bcp14">MUST</em> close the connection.1460 </p> 1461 <h3 id="rfc.section. 6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>1462 <p id="rfc.section. 6.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 9.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing1497 <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a> <a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3> 1498 <p id="rfc.section.7.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, 1499 it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section 3.3</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client <em class="bcp14">MUST</em> close the connection. 1500 </p> 1501 <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 1502 <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 9.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 1463 1503 to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either 1464 1504 be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking 1465 1505 at the body. 1466 1506 </p> 1467 <p id="rfc.section. 6.2.3.p.2">Requirements for HTTP/1.1 clients: </p>1507 <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p> 1468 1508 <ul> 1469 1509 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. … … 1472 1512 </li> 1473 1513 </ul> 1474 <p id="rfc.section. 6.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send "Expect:1514 <p id="rfc.section.7.2.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send "Expect: 1475 1515 100-continue" without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client 1476 1516 sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the 1477 1517 client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body. 1478 1518 </p> 1479 <p id="rfc.section. 6.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p>1519 <p id="rfc.section.7.2.3.p.4">Requirements for HTTP/1.1 origin servers: </p> 1480 1520 <ul> 1481 1521 <li>Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status and continue to read from the input stream, or respond with a final status code. … … 1501 1541 </li> 1502 1542 </ul> 1503 <p id="rfc.section. 6.2.3.p.5">Requirements for HTTP/1.1 proxies: </p>1543 <p id="rfc.section.7.2.3.p.5">Requirements for HTTP/1.1 proxies: </p> 1504 1544 <ul> 1505 1545 <li>If a proxy receives a request that includes an Expect request-header field with the "100-continue" expectation, and the proxy … … 1516 1556 </li> 1517 1557 </ul> 1518 <h3 id="rfc.section. 6.2.4"><a href="#rfc.section.6.2.4">6.2.4</a> <a id="connection.premature" href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></h3>1519 <p id="rfc.section. 6.2.4.p.1">If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect request-header field1558 <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a id="connection.premature" href="#connection.premature">Client Behavior if Server Prematurely Closes Connection</a></h3> 1559 <p id="rfc.section.7.2.4.p.1">If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect request-header field 1520 1560 with the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the 1521 1561 client sees the connection close before receiving any status from the server, the client <em class="bcp14">SHOULD</em> retry the request. If the client does retry this request, it <em class="bcp14">MAY</em> use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response: … … 1534 1574 </li> 1535 1575 </ol> 1536 <p id="rfc.section. 6.2.4.p.2">If at any point an error status is received, the client </p>1576 <p id="rfc.section.7.2.4.p.2">If at any point an error status is received, the client </p> 1537 1577 <ul> 1538 1578 <li><em class="bcp14">SHOULD NOT</em> continue and … … 1541 1581 </li> 1542 1582 </ul> 1543 <h1 id="rfc.section. 7"><a href="#rfc.section.7">7.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>1544 <p id="rfc.section. 7.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to message framing and transport protocols.</p>1545 <p id="rfc.section. 7.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who1583 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 1584 <p id="rfc.section.8.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to message framing and transport protocols.</p> 1585 <p id="rfc.section.8.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who 1546 1586 receives the entity. 1547 1587 </p> 1548 1588 <div id="rfc.iref.c.1"></div> 1549 1589 <div id="rfc.iref.h.3"></div> 1550 <h2 id="rfc.section. 7.1"><a href="#rfc.section.7.1">7.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2>1551 <p id="rfc.section. 7.1.p.1">The general-header field "Connection" allows the sender to specify options that are desired for that particular connection1590 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2> 1591 <p id="rfc.section.8.1.p.1">The general-header field "Connection" allows the sender to specify options that are desired for that particular connection 1552 1592 and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections. 1553 1593 </p> 1554 <p id="rfc.section. 7.1.p.2">The Connection header's value has the following grammar:</p>1555 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.8 5"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>1594 <p id="rfc.section.8.1.p.2">The Connection header's value has the following grammar:</p> 1595 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a> 1556 1596 <a href="#header.connection" class="smpl">Connection-v</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 1557 1597 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> 1558 </pre><p id="rfc.section. 7.1.p.4">HTTP/1.1 proxies <em class="bcp14">MUST</em> parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header1598 </pre><p id="rfc.section.8.1.p.4">HTTP/1.1 proxies <em class="bcp14">MUST</em> parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header 1559 1599 field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a 1560 1600 connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional 1561 1601 header field may not be sent if there are no parameters associated with that connection option. 1562 1602 </p> 1563 <p id="rfc.section. 7.1.p.5">Message headers listed in the Connection header <em class="bcp14">MUST NOT</em> include end-to-end headers, such as Cache-Control.1564 </p> 1565 <p id="rfc.section. 7.1.p.6">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion1603 <p id="rfc.section.8.1.p.5">Message headers listed in the Connection header <em class="bcp14">MUST NOT</em> include end-to-end headers, such as Cache-Control. 1604 </p> 1605 <p id="rfc.section.8.1.p.6">HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion 1566 1606 of the response. For example, 1567 1607 </p> 1568 1608 <div id="rfc.figure.u.43"></div><pre class="text"> Connection: close 1569 </pre><p id="rfc.section. 7.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered `persistent' (<a href="#persistent.connections" title="Persistent Connections">Section 6.1</a>) after the current request/response is complete.1570 </p> 1571 <p id="rfc.section. 7.1.p.9">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message.1572 </p> 1573 <p id="rfc.section. 7.1.p.10">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (informational) status code.1574 </p> 1575 <p id="rfc.section. 7.1.p.11">A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header <em class="bcp14">MUST</em>, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the1609 </pre><p id="rfc.section.8.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered `persistent' (<a href="#persistent.connections" title="Persistent Connections">Section 7.1</a>) after the current request/response is complete. 1610 </p> 1611 <p id="rfc.section.8.1.p.9">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message. 1612 </p> 1613 <p id="rfc.section.8.1.p.10">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (informational) status code. 1614 </p> 1615 <p id="rfc.section.8.1.p.11">A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header <em class="bcp14">MUST</em>, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the 1576 1616 connection-token. This protects against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix B.2</a>. 1577 1617 </p> 1578 1618 <div id="rfc.iref.c.2"></div> 1579 1619 <div id="rfc.iref.h.4"></div> 1580 <h2 id="rfc.section. 7.2"><a href="#rfc.section.7.2">7.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h2>1581 <p id="rfc.section. 7.2.p.1">The entity-header field "Content-Length" indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient1620 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h2> 1621 <p id="rfc.section.8.2.p.1">The entity-header field "Content-Length" indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient 1582 1622 or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. 1583 1623 </p> 1584 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.8 8"></span><span id="rfc.iref.g.89"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>1624 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a> 1585 1625 <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 1586 </pre><p id="rfc.section. 7.2.p.3">An example is</p>1626 </pre><p id="rfc.section.8.2.p.3">An example is</p> 1587 1627 <div id="rfc.figure.u.45"></div><pre class="text"> Content-Length: 3495 1588 </pre><p id="rfc.section. 7.2.p.5">Applications <em class="bcp14">SHOULD</em> use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#message.length" title="Message Length">Section 3.4</a>.1589 </p> 1590 <p id="rfc.section. 7.2.p.6">Any Content-Length greater than or equal to zero is a valid value. <a href="#message.length" title="Message Length">Section 3.4</a> describes how to determine the length of a message-body if a Content-Length is not given.1591 </p> 1592 <p id="rfc.section. 7.2.p.7">Note that the meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional1628 </pre><p id="rfc.section.8.2.p.5">Applications <em class="bcp14">SHOULD</em> use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#message.length" title="Message Length">Section 4.4</a>. 1629 </p> 1630 <p id="rfc.section.8.2.p.6">Any Content-Length greater than or equal to zero is a valid value. <a href="#message.length" title="Message Length">Section 4.4</a> describes how to determine the length of a message-body if a Content-Length is not given. 1631 </p> 1632 <p id="rfc.section.8.2.p.7">Note that the meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional 1593 1633 field used within the "message/external-body" content-type. In HTTP, it <em class="bcp14">SHOULD</em> be sent whenever the message's length can be determined prior to being transferred, unless this is prohibited by the rules 1594 in <a href="#message.length" title="Message Length">Section 3.4</a>.1634 in <a href="#message.length" title="Message Length">Section 4.4</a>. 1595 1635 </p> 1596 1636 <div id="rfc.iref.d.1"></div> 1597 1637 <div id="rfc.iref.h.5"></div> 1598 <h2 id="rfc.section. 7.3"><a href="#rfc.section.7.3">7.3</a> <a id="header.date" href="#header.date">Date</a></h2>1599 <p id="rfc.section. 7.3.p.1">The general-header field "Date" represents the date and time at which the message was originated, having the same semantics1600 as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section 2.3.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.1601 </p> 1602 <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g. 90"></span><span id="rfc.iref.g.91"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a>1638 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="header.date" href="#header.date">Date</a></h2> 1639 <p id="rfc.section.8.3.p.1">The general-header field "Date" represents the date and time at which the message was originated, having the same semantics 1640 as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section 3.2.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1641 </p> 1642 <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a> 1603 1643 <a href="#header.date" class="smpl">Date-v</a> = <a href="#full.date" class="smpl">HTTP-date</a> 1604 </pre><p id="rfc.section. 7.3.p.3">An example is</p>1644 </pre><p id="rfc.section.8.3.p.3">An example is</p> 1605 1645 <div id="rfc.figure.u.47"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 1606 </pre><p id="rfc.section. 7.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:1646 </pre><p id="rfc.section.8.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 1607 1647 </p> 1608 1648 <ol> … … 1612 1652 is inconvenient or impossible to generate a valid Date. 1613 1653 </li> 1614 <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field. In this case, the rules in <a href="#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section 7.3.1</a> <em class="bcp14">MUST</em> be followed.1654 <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field. In this case, the rules in <a href="#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section 8.3.1</a> <em class="bcp14">MUST</em> be followed. 1615 1655 </li> 1616 1656 </ol> 1617 <p id="rfc.section. 7.3.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires1657 <p id="rfc.section.8.3.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires 1618 1658 a Date. An HTTP implementation without a clock <em class="bcp14">MUST NOT</em> cache responses without revalidating them on every use. An HTTP cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>, to synchronize its clock with a reliable external standard. 1619 1659 </p> 1620 <p id="rfc.section. 7.3.p.7">Clients <em class="bcp14">SHOULD</em> only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even1660 <p id="rfc.section.8.3.p.7">Clients <em class="bcp14">SHOULD</em> only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even 1621 1661 then it is optional. A client without a clock <em class="bcp14">MUST NOT</em> send a Date header field in a request. 1622 1662 </p> 1623 <p id="rfc.section. 7.3.p.8">The HTTP-date sent in a Date header <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means1663 <p id="rfc.section.8.3.p.8">The HTTP-date sent in a Date header <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means 1624 1664 of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the entity 1625 1665 is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic 1626 1666 value. 1627 1667 </p> 1628 <h3 id="rfc.section. 7.3.1"><a href="#rfc.section.7.3.1">7.3.1</a> <a id="clockless.origin.server.operation" href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></h3>1629 <p id="rfc.section. 7.3.1.p.1">Some origin server implementations might not have a clock available. An origin server without a clock <em class="bcp14">MUST NOT</em> assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or1668 <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a id="clockless.origin.server.operation" href="#clockless.origin.server.operation">Clockless Origin Server Operation</a></h3> 1669 <p id="rfc.section.8.3.1.p.1">Some origin server implementations might not have a clock available. An origin server without a clock <em class="bcp14">MUST NOT</em> assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or 1630 1670 user with a reliable clock. It <em class="bcp14">MAY</em> assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration" 1631 1671 of responses without storing separate Expires values for each resource). … … 1633 1673 <div id="rfc.iref.h.6"></div> 1634 1674 <div id="rfc.iref.h.7"></div> 1635 <h2 id="rfc.section. 7.4"><a href="#rfc.section.7.4">7.4</a> <a id="header.host" href="#header.host">Host</a></h2>1636 <p id="rfc.section. 7.4.p.1">The request-header field "Host" specifies the Internet host and port number of the resource being requested, as obtained from1637 the original URI given by the user or referring resource (generally an HTTP URL, as described in <a href="#http.uri" title="http URI scheme">Section 2.2.1</a>). The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or1675 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="header.host" href="#header.host">Host</a></h2> 1676 <p id="rfc.section.8.4.p.1">The request-header field "Host" specifies the Internet host and port number of the resource being requested, as obtained from 1677 the original URI given by the user or referring resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section 2.1.1</a>). The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or 1638 1678 gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on 1639 1679 a single IP address. 1640 1680 </p> 1641 <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.9 2"></span><span id="rfc.iref.g.93"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a>1642 <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2. 2.1</a>1643 </pre><p id="rfc.section. 7.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP1681 <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a> 1682 <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.1.1</a> 1683 </pre><p id="rfc.section.8.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP 1644 1684 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 1645 1685 </p> 1646 1686 <div id="rfc.figure.u.49"></div><pre class="text"> GET /pub/WWW/ HTTP/1.1 1647 1687 Host: www.example.org 1648 </pre><p id="rfc.section. 7.4.p.5">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name1688 </pre><p id="rfc.section.8.4.p.5">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name 1649 1689 for the service being requested, then the Host header field <em class="bcp14">MUST</em> be given with an empty value. An HTTP/1.1 proxy <em class="bcp14">MUST</em> ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being 1650 1690 requested by the proxy. All Internet-based HTTP/1.1 servers <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field. 1651 1691 </p> 1652 <p id="rfc.section. 7.4.p.6">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host.1692 <p id="rfc.section.8.4.p.6">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host. 1653 1693 </p> 1654 1694 <div id="rfc.iref.t.1"></div> 1655 1695 <div id="rfc.iref.h.8"></div> 1656 <h2 id="rfc.section. 7.5"><a href="#rfc.section.7.5">7.5</a> <a id="header.te" href="#header.te">TE</a></h2>1657 <p id="rfc.section. 7.5.p.1">The request-header field "TE" indicates what extension transfer-codings it is willing to accept in the response and whether1696 <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="header.te" href="#header.te">TE</a></h2> 1697 <p id="rfc.section.8.5.p.1">The request-header field "TE" indicates what extension transfer-codings it is willing to accept in the response and whether 1658 1698 or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers" 1659 and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 2.4</a>).1660 </p> 1661 <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.9 4"></span><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a>1699 and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 3.3</a>). 1700 </p> 1701 <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a> 1662 1702 <a href="#header.te" class="smpl">TE-v</a> = #<a href="#header.te" class="smpl">t-codings</a> 1663 1703 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#abnf.dependencies" class="smpl">accept-params</a> ] ) 1664 </pre><p id="rfc.section. 7.5.p.3">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,1665 as defined in <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 2.4.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.1666 </p> 1667 <p id="rfc.section. 7.5.p.4">Examples of its use are:</p>1704 </pre><p id="rfc.section.8.5.p.3">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding, 1705 as defined in <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.3.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding. 1706 </p> 1707 <p id="rfc.section.8.5.p.4">Examples of its use are:</p> 1668 1708 <div id="rfc.figure.u.51"></div><pre class="text"> TE: deflate 1669 1709 TE: 1670 1710 TE: trailers, deflate;q=0.5 1671 </pre><p id="rfc.section. 7.5.p.6">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 7.1</a>) whenever TE is present in an HTTP/1.1 message.1672 </p> 1673 <p id="rfc.section. 7.5.p.7">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>1711 </pre><p id="rfc.section.8.5.p.6">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 8.1</a>) whenever TE is present in an HTTP/1.1 message. 1712 </p> 1713 <p id="rfc.section.8.5.p.7">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p> 1674 1714 <ol> 1675 1715 <li> … … 1685 1725 <li> 1686 1726 <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it 1687 is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 3.4</a> of <a href="#Part3" id="rfc.xref.Part3.1 2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.")1727 is accompanied by a qvalue of 0. (As defined in <a href="p3-payload.html#quality.values" title="Quality Values">Section 3.4</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, a qvalue of 0 means "not acceptable.") 1688 1728 </p> 1689 1729 </li> … … 1694 1734 </li> 1695 1735 </ol> 1696 <p id="rfc.section. 7.5.p.8">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding1736 <p id="rfc.section.8.5.p.8">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding 1697 1737 is always acceptable. 1698 1738 </p> 1699 1739 <div id="rfc.iref.t.2"></div> 1700 1740 <div id="rfc.iref.h.9"></div> 1701 <h2 id="rfc.section. 7.6"><a href="#rfc.section.7.6">7.6</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2>1702 <p id="rfc.section. 7.6.p.1">The general field "Trailer" indicates that the given set of header fields is present in the trailer of a message encoded with1741 <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2> 1742 <p id="rfc.section.8.6.p.1">The general field "Trailer" indicates that the given set of header fields is present in the trailer of a message encoded with 1703 1743 chunked transfer-coding. 1704 1744 </p> 1705 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.9 7"></span><span id="rfc.iref.g.98"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>1745 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a> 1706 1746 <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#message.headers" class="smpl">field-name</a> 1707 </pre><p id="rfc.section. 7.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient1747 </pre><p id="rfc.section.8.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient 1708 1748 to know which header fields to expect in the trailer. 1709 1749 </p> 1710 <p id="rfc.section. 7.6.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 2.4.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.1711 </p> 1712 <p id="rfc.section. 7.6.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:1750 <p id="rfc.section.8.6.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.3.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding. 1751 </p> 1752 <p id="rfc.section.8.6.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields: 1713 1753 </p> 1714 1754 <ul> … … 1719 1759 <div id="rfc.iref.t.3"></div> 1720 1760 <div id="rfc.iref.h.10"></div> 1721 <h2 id="rfc.section. 7.7"><a href="#rfc.section.7.7">7.7</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>1722 <p id="rfc.section. 7.7.p.1">The general-header "Transfer-Encoding" field indicates what (if any) type of transformation has been applied to the message1761 <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2> 1762 <p id="rfc.section.8.7.p.1">The general-header "Transfer-Encoding" field indicates what (if any) type of transformation has been applied to the message 1723 1763 body in order to safely transfer it between the sender and the recipient. This differs from the content-coding in that the 1724 1764 transfer-coding is a property of the message, not of the entity. 1725 1765 </p> 1726 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.9 9"></span><span id="rfc.iref.g.100"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>1766 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1727 1767 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> 1728 1768 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 1729 </pre><p id="rfc.section. 7.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 2.4</a>. An example is:1769 </pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 3.3</a>. An example is: 1730 1770 </p> 1731 1771 <div id="rfc.figure.u.54"></div><pre class="text"> Transfer-Encoding: chunked 1732 </pre><p id="rfc.section. 7.7.p.5">If multiple encodings have been applied to an entity, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification.1733 </p> 1734 <p id="rfc.section. 7.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header.</p>1772 </pre><p id="rfc.section.8.7.p.5">If multiple encodings have been applied to an entity, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification. 1773 </p> 1774 <p id="rfc.section.8.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header.</p> 1735 1775 <div id="rfc.iref.u.3"></div> 1736 1776 <div id="rfc.iref.h.11"></div> 1737 <h2 id="rfc.section. 7.8"><a href="#rfc.section.7.8">7.8</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>1738 <p id="rfc.section. 7.8.p.1">The general-header "Upgrade" allows the client to specify what additional communication protocols it supports and would like1777 <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> 1778 <p id="rfc.section.8.8.p.1">The general-header "Upgrade" allows the client to specify what additional communication protocols it supports and would like 1739 1779 to use if the server finds it appropriate to switch protocols. The server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched. 1740 1780 </p> 1741 <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g. 101"></span><span id="rfc.iref.g.102"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a>1781 <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a> 1742 1782 <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a> 1743 </pre><p id="rfc.section. 7.8.p.3">For example,</p>1783 </pre><p id="rfc.section.8.8.p.3">For example,</p> 1744 1784 <div id="rfc.figure.u.56"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 1745 </pre><p id="rfc.section. 7.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible1785 </pre><p id="rfc.section.8.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible 1746 1786 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP 1747 1787 with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult … … 1750 1790 the server, possibly according to the nature of the method and/or resource being requested). 1751 1791 </p> 1752 <p id="rfc.section. 7.8.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.1792 <p id="rfc.section.8.8.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. 1753 1793 Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities 1754 1794 and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, 1755 1795 although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field. 1756 1796 </p> 1757 <p id="rfc.section. 7.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section 7.1</a>) whenever Upgrade is present in an HTTP/1.1 message.1758 </p> 1759 <p id="rfc.section. 7.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it1797 <p id="rfc.section.8.8.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.5" title="Connection">Section 8.1</a>) whenever Upgrade is present in an HTTP/1.1 message. 1798 </p> 1799 <p id="rfc.section.8.8.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 1760 1800 is more appropriate to use a 301, 302, 303, or 305 redirection response. 1761 1801 </p> 1762 <p id="rfc.section. 7.8.p.9">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined1763 by the HTTP version rules of <a href="#http.version" title="HTTP Version">Section 2.1</a> and future updates to this specification. Any token can be used as a protocol name; however, it will only be useful if both1802 <p id="rfc.section.8.8.p.9">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 1803 by the HTTP version rules of <a href="#http.version" title="HTTP Version">Section 3.1</a> and future updates to this specification. Any token can be used as a protocol name; however, it will only be useful if both 1764 1804 the client and server associate the name with the same protocol. 1765 1805 </p> 1766 1806 <div id="rfc.iref.v.1"></div> 1767 1807 <div id="rfc.iref.h.12"></div> 1768 <h2 id="rfc.section. 7.9"><a href="#rfc.section.7.9">7.9</a> <a id="header.via" href="#header.via">Via</a></h2>1769 <p id="rfc.section. 7.9.p.1">The general-header field "Via" <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server1808 <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a> <a id="header.via" href="#header.via">Via</a></h2> 1809 <p id="rfc.section.8.9.p.1">The general-header field "Via" <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server 1770 1810 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities 1771 1811 of all senders along the request/response chain. 1772 1812 </p> 1773 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.10 3"></span><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span><span id="rfc.iref.g.109"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a>1813 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span><span id="rfc.iref.g.107"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a> 1774 1814 <a href="#header.via" class="smpl">Via-v</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> 1775 1815 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) … … 1779 1819 <a href="#header.via" class="smpl">received-by</a> = ( <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ) / <a href="#header.via" class="smpl">pseudonym</a> 1780 1820 <a href="#header.via" class="smpl">pseudonym</a> = <a href="#rule.token.separators" class="smpl">token</a> 1781 </pre><p id="rfc.section. 7.9.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of1821 </pre><p id="rfc.section.8.9.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of 1782 1822 the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded 1783 1823 so that information about the protocol capabilities of upstream applications remains visible to all recipients. 1784 1824 </p> 1785 <p id="rfc.section. 7.9.p.4">The protocol-name is optional if and only if it would be "HTTP". The received-by field is normally the host and optional port1825 <p id="rfc.section.8.9.p.4">The protocol-name is optional if and only if it would be "HTTP". The received-by field is normally the host and optional port 1786 1826 number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to 1787 1827 be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol. 1788 1828 </p> 1789 <p id="rfc.section. 7.9.p.5">Multiple Via field values represents each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.1790 </p> 1791 <p id="rfc.section. 7.9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and1829 <p id="rfc.section.8.9.p.5">Multiple Via field values represents each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications. 1830 </p> 1831 <p id="rfc.section.8.9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and 1792 1832 Server header fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message. 1793 1833 </p> 1794 <p id="rfc.section. 7.9.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses1834 <p id="rfc.section.8.9.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses 1795 1835 HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin 1796 1836 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1797 1837 </p> 1798 1838 <div id="rfc.figure.u.58"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 1799 </pre><p id="rfc.section. 7.9.p.9">Proxies and gateways used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.1800 </p> 1801 <p id="rfc.section. 7.9.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.1839 </pre><p id="rfc.section.8.9.p.9">Proxies and gateways used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 1840 </p> 1841 <p id="rfc.section.8.9.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry. 1802 1842 For example, 1803 1843 </p> 1804 1844 <div id="rfc.figure.u.59"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 1805 </pre><p id="rfc.section. 7.9.p.12">could be collapsed to</p>1845 </pre><p id="rfc.section.8.9.p.12">could be collapsed to</p> 1806 1846 <div id="rfc.figure.u.60"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 1807 </pre><p id="rfc.section. 7.9.p.14">Applications <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced1847 </pre><p id="rfc.section.8.9.p.14">Applications <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 1808 1848 by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. 1809 1849 </p> 1810 <h1 id="rfc.section. 8"><a href="#rfc.section.8">8.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>1811 <h2 id="rfc.section. 8.1"><a href="#rfc.section.8.1">8.1</a> <a id="message.header.registration" href="#message.header.registration">Message Header Registration</a></h2>1812 <p id="rfc.section. 8.1.p.1">The Message Header Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):1850 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1851 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="message.header.registration" href="#message.header.registration">Message Header Registration</a></h2> 1852 <p id="rfc.section.9.1.p.1">The Message Header Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 1813 1853 </p> 1814 1854 <div id="rfc.table.1"> … … 1828 1868 <td>http</td> 1829 1869 <td>standard</td> 1830 <td> <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 7.1</a>1870 <td> <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 8.1</a> 1831 1871 </td> 1832 1872 </tr> … … 1835 1875 <td>http</td> 1836 1876 <td>standard</td> 1837 <td> <a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section 7.2</a>1877 <td> <a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section 8.2</a> 1838 1878 </td> 1839 1879 </tr> … … 1842 1882 <td>http</td> 1843 1883 <td>standard</td> 1844 <td> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 7.3</a>1884 <td> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 8.3</a> 1845 1885 </td> 1846 1886 </tr> … … 1849 1889 <td>http</td> 1850 1890 <td>standard</td> 1851 <td> <a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 7.4</a>1891 <td> <a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section 8.4</a> 1852 1892 </td> 1853 1893 </tr> … … 1856 1896 <td>http</td> 1857 1897 <td>standard</td> 1858 <td> <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 7.5</a>1898 <td> <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 8.5</a> 1859 1899 </td> 1860 1900 </tr> … … 1863 1903 <td>http</td> 1864 1904 <td>standard</td> 1865 <td> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section 7.6</a>1905 <td> <a href="#header.trailer" id="rfc.xref.header.trailer.3" title="Trailer">Section 8.6</a> 1866 1906 </td> 1867 1907 </tr> … … 1870 1910 <td>http</td> 1871 1911 <td>standard</td> 1872 <td> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.5" title="Transfer-Encoding">Section 7.7</a>1912 <td> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.5" title="Transfer-Encoding">Section 8.7</a> 1873 1913 </td> 1874 1914 </tr> … … 1877 1917 <td>http</td> 1878 1918 <td>standard</td> 1879 <td> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 7.8</a>1919 <td> <a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 8.8</a> 1880 1920 </td> 1881 1921 </tr> … … 1884 1924 <td>http</td> 1885 1925 <td>standard</td> 1886 <td> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 7.9</a>1926 <td> <a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 8.9</a> 1887 1927 </td> 1888 1928 </tr> … … 1890 1930 </table> 1891 1931 </div> 1892 <p id="rfc.section. 8.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>1893 <h2 id="rfc.section. 8.2"><a href="#rfc.section.8.2">8.2</a> <a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2>1894 <p id="rfc.section. 8.2.p.1">The entry for the "http" URI Scheme in the registry located at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>> should be updated to point to <a href="#http.uri" title="http URI scheme">Section 2.2.1</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>).1895 </p> 1896 <h2 id="rfc.section. 8.3"><a href="#rfc.section.8.3">8.3</a> <a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2>1897 <p id="rfc.section. 8.3.p.1">This document serves as the specification for the Internet media types "message/http" and "application/http". The following1932 <p id="rfc.section.9.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 1933 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2> 1934 <p id="rfc.section.9.2.p.1">The entry for the "http" URI Scheme in the registry located at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>> should be updated to point to <a href="#http.uri" title="http URI scheme">Section 2.1.1</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>). 1935 </p> 1936 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2> 1937 <p id="rfc.section.9.3.p.1">This document serves as the specification for the Internet media types "message/http" and "application/http". The following 1898 1938 is to be registered with IANA (see <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>). 1899 1939 </p> 1900 1940 <div id="rfc.iref.m.1"></div> 1901 1941 <div id="rfc.iref.m.2"></div> 1902 <h3 id="rfc.section. 8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a id="internet.media.type.message.http" href="#internet.media.type.message.http">Internet Media Type message/http</a></h3>1903 <p id="rfc.section. 8.3.1.p.1">The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions1942 <h3 id="rfc.section.9.3.1"><a href="#rfc.section.9.3.1">9.3.1</a> <a id="internet.media.type.message.http" href="#internet.media.type.message.http">Internet Media Type message/http</a></h3> 1943 <p id="rfc.section.9.3.1.p.1">The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions 1904 1944 for all "message" types regarding line length and encodings. 1905 1945 </p> 1906 <p id="rfc.section. 8.3.1.p.2"> </p>1946 <p id="rfc.section.9.3.1.p.2"> </p> 1907 1947 <dl> 1908 1948 <dt>Type name:</dt> … … 1930 1970 <dd>none</dd> 1931 1971 <dt>Published specification:</dt> 1932 <dd>This specification (see <a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 8.3.1</a>).1972 <dd>This specification (see <a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a>). 1933 1973 </dd> 1934 1974 <dt>Applications that use this media type:</dt> … … 1955 1995 <div id="rfc.iref.m.3"></div> 1956 1996 <div id="rfc.iref.a.1"></div> 1957 <h3 id="rfc.section. 8.3.2"><a href="#rfc.section.8.3.2">8.3.2</a> <a id="internet.media.type.application.http" href="#internet.media.type.application.http">Internet Media Type application/http</a></h3>1958 <p id="rfc.section. 8.3.2.p.1">The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).</p>1959 <p id="rfc.section. 8.3.2.p.2"> </p>1997 <h3 id="rfc.section.9.3.2"><a href="#rfc.section.9.3.2">9.3.2</a> <a id="internet.media.type.application.http" href="#internet.media.type.application.http">Internet Media Type application/http</a></h3> 1998 <p id="rfc.section.9.3.2.p.1">The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).</p> 1999 <p id="rfc.section.9.3.2.p.2"> </p> 1960 2000 <dl> 1961 2001 <dt>Type name:</dt> … … 1985 2025 <dd>none</dd> 1986 2026 <dt>Published specification:</dt> 1987 <dd>This specification (see <a href="#internet.media.type.application.http" title="Internet Media Type application/http">Section 8.3.2</a>).2027 <dd>This specification (see <a href="#internet.media.type.application.http" title="Internet Media Type application/http">Section 9.3.2</a>). 1988 2028 </dd> 1989 2029 <dt>Applications that use this media type:</dt> … … 2008 2048 <dd>IESG</dd> 2009 2049 </dl> 2010 <h1 id="rfc.section. 9"><a href="#rfc.section.9">9.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>2011 <p id="rfc.section. 9.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.12050 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 2051 <p id="rfc.section.10.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 2012 2052 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does 2013 2053 make some suggestions for reducing security risks. 2014 2054 </p> 2015 <h2 id="rfc.section. 9.1"><a href="#rfc.section.9.1">9.1</a> <a id="personal.information" href="#personal.information">Personal Information</a></h2>2016 <p id="rfc.section. 9.1.p.1">HTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords,2055 <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a> <a id="personal.information" href="#personal.information">Personal Information</a></h2> 2056 <p id="rfc.section.10.1.p.1">HTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords, 2017 2057 encryption keys, etc.), and <em class="bcp14">SHOULD</em> be very careful to prevent unintentional leakage of this information. We very strongly recommend that a convenient interface 2018 2058 be provided for the user to control dissemination of such information, and that designers and implementors be particularly … … 2020 2060 highly adverse publicity for the implementor's company. 2021 2061 </p> 2022 <h2 id="rfc.section. 9.2"><a href="#rfc.section.9.2">9.2</a> <a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2>2023 <p id="rfc.section. 9.2.p.1">A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects2062 <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> <a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2> 2063 <p id="rfc.section.10.2.p.1">A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects 2024 2064 of interest. This information is clearly confidential in nature and its handling can be constrained by law in certain countries. 2025 2065 People using HTTP to provide data are responsible for ensuring that such material is not distributed without the permission 2026 2066 of any individuals that are identifiable by the published results. 2027 2067 </p> 2028 <h2 id="rfc.section. 9.3"><a href="#rfc.section.9.3">9.3</a> <a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>2029 <p id="rfc.section. 9.3.p.1">Implementations of HTTP origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators.2068 <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2> 2069 <p id="rfc.section.10.3.p.1">Implementations of HTTP origin servers <em class="bcp14">SHOULD</em> be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators. 2030 2070 If an HTTP server translates HTTP URIs directly into file system calls, the server <em class="bcp14">MUST</em> take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft 2031 2071 Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On 2032 such a system, an HTTP server <em class="bcp14">MUST</em> disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside those intended to2033 be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access control2034 files, configuration files, and script code) <em class="bcp14">MUST</em> be protected from inappropriate retrieval, since they might contain sensitive information. Experience has shown that minor2072 such a system, an HTTP server <em class="bcp14">MUST</em> disallow any such construct in the request-target if it would otherwise allow access to a resource outside those intended 2073 to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access 2074 control files, configuration files, and script code) <em class="bcp14">MUST</em> be protected from inappropriate retrieval, since they might contain sensitive information. Experience has shown that minor 2035 2075 bugs in such HTTP server implementations have turned into security risks. 2036 2076 </p> 2037 <h2 id="rfc.section. 9.4"><a href="#rfc.section.9.4">9.4</a> <a id="dns.spoofing" href="#dns.spoofing">DNS Spoofing</a></h2>2038 <p id="rfc.section. 9.4.p.1">Clients using HTTP rely heavily on the Domain Name Service, and are thus generally prone to security attacks based on the2077 <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a> <a id="dns.spoofing" href="#dns.spoofing">DNS Spoofing</a></h2> 2078 <p id="rfc.section.10.4.p.1">Clients using HTTP rely heavily on the Domain Name Service, and are thus generally prone to security attacks based on the 2039 2079 deliberate mis-association of IP addresses and DNS names. Clients need to be cautious in assuming the continuing validity 2040 2080 of an IP number/DNS name association. 2041 2081 </p> 2042 <p id="rfc.section. 9.4.p.2">In particular, HTTP clients <em class="bcp14">SHOULD</em> rely on their name resolver for confirmation of an IP number/DNS name association, rather than caching the result of previous2082 <p id="rfc.section.10.4.p.2">In particular, HTTP clients <em class="bcp14">SHOULD</em> rely on their name resolver for confirmation of an IP number/DNS name association, rather than caching the result of previous 2043 2083 host name lookups. Many platforms already can cache host name lookups locally when appropriate, and they <em class="bcp14">SHOULD</em> be configured to do so. It is proper for these lookups to be cached, however, only when the TTL (Time To Live) information 2044 2084 reported by the name server makes it likely that the cached information will remain useful. 2045 2085 </p> 2046 <p id="rfc.section. 9.4.p.3">If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they <em class="bcp14">MUST</em> observe the TTL information reported by DNS.2047 </p> 2048 <p id="rfc.section. 9.4.p.4">If HTTP clients do not observe this rule, they could be spoofed when a previously-accessed server's IP address changes. As2086 <p id="rfc.section.10.4.p.3">If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they <em class="bcp14">MUST</em> observe the TTL information reported by DNS. 2087 </p> 2088 <p id="rfc.section.10.4.p.4">If HTTP clients do not observe this rule, they could be spoofed when a previously-accessed server's IP address changes. As 2049 2089 network renumbering is expected to become increasingly common <a href="#RFC1900" id="rfc.xref.RFC1900.2"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>, the possibility of this form of attack will grow. Observing this requirement thus reduces this potential security vulnerability. 2050 2090 </p> 2051 <p id="rfc.section. 9.4.p.5">This requirement also improves the load-balancing behavior of clients for replicated servers using the same DNS name and reduces2091 <p id="rfc.section.10.4.p.5">This requirement also improves the load-balancing behavior of clients for replicated servers using the same DNS name and reduces 2052 2092 the likelihood of a user's experiencing failure in accessing sites which use that strategy. 2053 2093 </p> 2054 <h2 id="rfc.section. 9.5"><a href="#rfc.section.9.5">9.5</a> <a id="attack.proxies" href="#attack.proxies">Proxies and Caching</a></h2>2055 <p id="rfc.section. 9.5.p.1">By their very nature, HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Compromise2094 <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a> <a id="attack.proxies" href="#attack.proxies">Proxies and Caching</a></h2> 2095 <p id="rfc.section.10.5.p.1">By their very nature, HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Compromise 2056 2096 of the systems on which the proxies run can result in serious security and privacy problems. Proxies have access to security-related 2057 2097 information, personal information about individual users and organizations, and proprietary information belonging to users … … 2059 2099 might be used in the commission of a wide range of potential attacks. 2060 2100 </p> 2061 <p id="rfc.section. 9.5.p.2">Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports2101 <p id="rfc.section.10.5.p.2">Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports 2062 2102 sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information, 2063 2103 and/or information about organizations. Log information should be carefully guarded, and appropriate guidelines for use developed 2064 and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section 9.2</a>).2065 </p> 2066 <p id="rfc.section. 9.5.p.3">Proxy implementors should consider the privacy and security implications of their design and coding decisions, and of the2104 and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section 10.2</a>). 2105 </p> 2106 <p id="rfc.section.10.5.p.3">Proxy implementors should consider the privacy and security implications of their design and coding decisions, and of the 2067 2107 configuration options they provide to proxy operators (especially the default configuration). 2068 2108 </p> 2069 <p id="rfc.section. 9.5.p.4">Users of a proxy need to be aware that they are no trustworthier than the people who run the proxy; HTTP itself cannot solve2109 <p id="rfc.section.10.5.p.4">Users of a proxy need to be aware that they are no trustworthier than the people who run the proxy; HTTP itself cannot solve 2070 2110 this problem. 2071 2111 </p> 2072 <p id="rfc.section. 9.5.p.5">The judicious use of cryptography, when appropriate, may suffice to protect against a broad range of security and privacy2112 <p id="rfc.section.10.5.p.5">The judicious use of cryptography, when appropriate, may suffice to protect against a broad range of security and privacy 2073 2113 attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification. 2074 2114 </p> 2075 <h2 id="rfc.section. 9.6"><a href="#rfc.section.9.6">9.6</a> <a id="attack.DoS" href="#attack.DoS">Denial of Service Attacks on Proxies</a></h2>2076 <p id="rfc.section. 9.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>2077 <h1 id="rfc.section.1 0"><a href="#rfc.section.10">10.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>2078 <p id="rfc.section.1 0.p.1">HTTP has evolved considerably over the years. It has benefited from a large and active developer community--the many people2115 <h2 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a> <a id="attack.DoS" href="#attack.DoS">Denial of Service Attacks on Proxies</a></h2> 2116 <p id="rfc.section.10.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p> 2117 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 2118 <p id="rfc.section.11.p.1">HTTP has evolved considerably over the years. It has benefited from a large and active developer community--the many people 2079 2119 who have participated on the www-talk mailing list--and it is that community which has been most responsible for the success 2080 2120 of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks, … … 2082 2122 and Marc VanHeyningen deserve special recognition for their efforts in defining early aspects of the protocol. 2083 2123 </p> 2084 <p id="rfc.section.1 0.p.2">This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already2124 <p id="rfc.section.11.p.2">This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already 2085 2125 mentioned, the following individuals have contributed to this specification: 2086 2126 </p> 2087 <p id="rfc.section.1 0.p.3">Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman2127 <p id="rfc.section.11.p.3">Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf, Paul Burchard, Maurizio Codogno, Mike Cowlishaw, Roman 2088 2128 Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, 2089 2129 Bob Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster, Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben … … 2093 2133 Weinman, Francois Yergeau, Mary Ellen Zurko, Josh Cohen. 2094 2134 </p> 2095 <p id="rfc.section.1 0.p.4">Thanks to the "cave men" of Palo Alto. You know who you are.</p>2096 <p id="rfc.section.1 0.p.5">Jim Gettys (the editor of <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) wishes particularly to thank Roy Fielding, the editor of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott2135 <p id="rfc.section.11.p.4">Thanks to the "cave men" of Palo Alto. You know who you are.</p> 2136 <p id="rfc.section.11.p.5">Jim Gettys (the editor of <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) wishes particularly to thank Roy Fielding, the editor of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott 2097 2137 Lawrence, and Larry Masinter for their help. And thanks go particularly to Jeff Mogul and Scott Lawrence for performing the 2098 2138 "MUST/MAY/SHOULD" audit. 2099 2139 </p> 2100 <p id="rfc.section.1 0.p.6">The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik Frystyk implemented RFC 2068 early, and we wish to thank2140 <p id="rfc.section.11.p.6">The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik Frystyk implemented RFC 2068 early, and we wish to thank 2101 2141 them for the discovery of many of the problems that this document attempts to rectify. 2102 2142 </p> 2103 <p id="rfc.section.1 0.p.7">This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for <a href="#RFC5234" id="rfc.xref.RFC5234.4"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and2143 <p id="rfc.section.11.p.7">This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for <a href="#RFC5234" id="rfc.xref.RFC5234.4"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and 2104 2144 Internet mail message formats. 2105 2145 </p> 2106 <h1 id="rfc.references"><a id="rfc.section.1 1" href="#rfc.section.11">11.</a> References2146 <h1 id="rfc.references"><a id="rfc.section.12" href="#rfc.section.12">12.</a> References 2107 2147 </h1> 2108 <h2 id="rfc.references.1"><a href="#rfc.section.1 1.1" id="rfc.section.11.1">11.1</a> Normative References2148 <h2 id="rfc.references.1"><a href="#rfc.section.12.1" id="rfc.section.12.1">12.1</a> Normative References 2109 2149 </h2> 2110 2150 <table summary="Normative References"> … … 2166 2206 </tr> 2167 2207 </table> 2168 <h2 id="rfc.references.2"><a href="#rfc.section.1 1.2" id="rfc.section.11.2">11.2</a> Informative References2208 <h2 id="rfc.references.2"><a href="#rfc.section.12.2" id="rfc.section.12.2">12.2</a> Informative References 2169 2209 </h2> 2170 2210 <table summary="Informative References"> … … 2312 2352 </p> 2313 2353 <p id="rfc.section.A.p.4">The character set of an entity-body <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling 2314 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.1 3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.2354 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2315 2355 </p> 2316 2356 <p id="rfc.section.A.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p> … … 2361 2401 <p id="rfc.section.B.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 2362 2402 <h3 id="rfc.section.B.1.1"><a href="#rfc.section.B.1.1">B.1.1</a> <a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></h3> 2363 <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host request-header, report an error if the Host request-header (<a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 7.4</a>) is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-uri" title="Request-URI">Section 4.1.2</a>) are among the most important changes defined by this specification.2403 <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host request-header, report an error if the Host request-header (<a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section 8.4</a>) is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section 5.1.2</a>) are among the most important changes defined by this specification. 2364 2404 </p> 2365 2405 <p id="rfc.section.B.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism … … 2394 2434 Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when 2395 2435 talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce 2396 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 7.1</a>.2436 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 8.1</a>. 2397 2437 </p> 2398 2438 <p id="rfc.section.B.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in <a href="#RFC2068" id="rfc.xref.RFC2068.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. … … 2404 2444 <p id="rfc.section.B.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 2405 2445 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 2406 computed. (Sections <a href="#transfer.codings" title="Transfer Codings"> 2.4</a>, <a href="#message.length" title="Message Length">3.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">7.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.14"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)2446 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">3.3</a>, <a href="#message.length" title="Message Length">4.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">8.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) 2407 2447 </p> 2408 2448 <p id="rfc.section.B.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0 2409 implementations (<a href="#http.version" title="HTTP Version">Section 2.1</a>)2449 implementations (<a href="#http.version" title="HTTP Version">Section 3.1</a>) 2410 2450 </p> 2411 2451 <p id="rfc.section.B.3.p.4">Transfer-coding had significant problems, particularly with interactions with chunked encoding. The solution is that transfer-codings … … 2413 2453 codings), a new header field (TE) and enabling trailer headers in the future. Transfer encoding is a major performance benefit, 2414 2454 so it was worth fixing <a href="#Nie1997" id="rfc.xref.Nie1997.2"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. TE also solves another, obscure, downward interoperability problem that could have occurred due to interactions between 2415 authentication trailers, chunked encoding and HTTP/1.0 clients.(Section <a href="#transfer.codings" title="Transfer Codings"> 2.4</a>, <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">2.4.1</a>, and <a href="#header.te" id="rfc.xref.header.te.4" title="TE">7.5</a>)2455 authentication trailers, chunked encoding and HTTP/1.0 clients.(Section <a href="#transfer.codings" title="Transfer Codings">3.3</a>, <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">3.3.1</a>, and <a href="#header.te" id="rfc.xref.header.te.4" title="TE">8.5</a>) 2416 2456 </p> 2417 2457 <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> … … 2420 2460 quoted-string rules). Furthermore, the quoted-pair rule does not allow escaping NUL, CR or LF anymore. (<a href="#basic.rules" title="Basic Rules">Section 1.2.2</a>) 2421 2461 </p> 2422 <p id="rfc.section.B.4.p.2">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="HTTP Version">Section 2.1</a>)2423 </p> 2424 <p id="rfc.section.B.4.p.3">Remove reference to non-existant identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings"> 2.4</a> and <a href="#message.length" title="Message Length">3.4</a>)2425 </p> 2426 <p id="rfc.section.B.4.p.4">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 2.4.1</a>)2427 </p> 2428 <p id="rfc.section.B.4.p.5">Update use of abs_path production from RFC1808 to the path-absolute + query components of RFC3986. (<a href="#request- uri" title="Request-URI">Section 4.1.2</a>)2429 </p> 2430 <p id="rfc.section.B.4.p.6">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 7.1</a>)2462 <p id="rfc.section.B.4.p.2">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="HTTP Version">Section 3.1</a>) 2463 </p> 2464 <p id="rfc.section.B.4.p.3">Remove reference to non-existant identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">3.3</a> and <a href="#message.length" title="Message Length">4.4</a>) 2465 </p> 2466 <p id="rfc.section.B.4.p.4">Clarification that the chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.3.1</a>) 2467 </p> 2468 <p id="rfc.section.B.4.p.5">Update use of abs_path production from RFC1808 to the path-absolute + query components of RFC3986. (<a href="#request-target" title="request-target">Section 5.1.2</a>) 2469 </p> 2470 <p id="rfc.section.B.4.p.6">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 8.1</a>) 2431 2471 </p> 2432 2472 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="terminology" href="#terminology">Terminology</a></h1> … … 2440 2480 </p> 2441 2481 <dl class="empty"> 2442 <dd>The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in <a href="#http.message" title="HTTP Message">Section 3</a> and transmitted via the connection.2482 <dd>The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in <a href="#http.message" title="HTTP Message">Section 4</a> and transmitted via the connection. 2443 2483 </dd> 2444 2484 </dl> … … 2446 2486 </p> 2447 2487 <dl class="empty"> 2448 <dd>An HTTP request message, as defined in <a href="#request" title="Request">Section 4</a>.2488 <dd>An HTTP request message, as defined in <a href="#request" title="Request">Section 5</a>. 2449 2489 </dd> 2450 2490 </dl> … … 2452 2492 </p> 2453 2493 <dl class="empty"> 2454 <dd>An HTTP response message, as defined in <a href="#response" title="Response">Section 5</a>.2494 <dd>An HTTP response message, as defined in <a href="#response" title="Response">Section 6</a>. 2455 2495 </dd> 2456 2496 </dl> … … 2458 2498 </p> 2459 2499 <dl class="empty"> 2460 <dd>A network data object or service that can be identified by a URI, as defined in <a href="#uri" title="Uniform Resource Identifiers">Section 2. 2</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or2500 <dd>A network data object or service that can be identified by a URI, as defined in <a href="#uri" title="Uniform Resource Identifiers">Section 2.1</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or 2461 2501 vary in other ways. 2462 2502 </dd> … … 2466 2506 <dl class="empty"> 2467 2507 <dd>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of 2468 entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" title="Entity">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.1 5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.2508 entity-header fields and content in the form of an entity-body, as described in <a href="p3-payload.html#entity" title="Entity">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.14"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2469 2509 </dd> 2470 2510 </dl> … … 2472 2512 </p> 2473 2513 <dl class="empty"> 2474 <dd>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.1 6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status.2514 <dd>An entity included with a response that is subject to content negotiation, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.15"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. There may exist multiple representations associated with a particular response status. 2475 2515 </dd> 2476 2516 </dl> … … 2478 2518 </p> 2479 2519 <dl class="empty"> 2480 <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.1 7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses).2520 <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.16"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. The representation of entities in any response can be negotiated (including error responses). 2481 2521 </dd> 2482 2522 </dl> … … 2525 2565 </dd> 2526 2566 </dl> 2527 <p id="rfc.section.C.p.16"> <span id="rfc.iref.g.1 10"></span> <dfn>gateway</dfn>2567 <p id="rfc.section.C.p.16"> <span id="rfc.iref.g.108"></span> <dfn>gateway</dfn> 2528 2568 </p> 2529 2569 <dl class="empty"> … … 2745 2785 <ul class="ind"> 2746 2786 <li class="indline0"><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind"> 2747 <li class="indline1">application/http Media Type <a class="iref" href="#rfc.iref.a.1"><b> 8.3.2</b></a></li>2787 <li class="indline1">application/http Media Type <a class="iref" href="#rfc.iref.a.1"><b>9.3.2</b></a></li> 2748 2788 </ul> 2749 2789 </li> … … 2753 2793 <li class="indline1">client <a class="iref" href="#rfc.iref.c.5">C</a></li> 2754 2794 <li class="indline1">connection <a class="iref" href="#rfc.iref.c.3">C</a></li> 2755 <li class="indline1">Connection header <a class="iref" href="#rfc.xref.header.connection.1"> 3.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">6.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">6.1.3</a>, <a class="iref" href="#rfc.iref.c.1"><b>7.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.4">7.5</a>, <a class="iref" href="#rfc.xref.header.connection.5">7.8</a>, <a class="iref" href="#rfc.xref.header.connection.6">8.1</a>, <a class="iref" href="#rfc.xref.header.connection.7">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.4</a></li>2795 <li class="indline1">Connection header <a class="iref" href="#rfc.xref.header.connection.1">4.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.iref.c.1"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.4">8.5</a>, <a class="iref" href="#rfc.xref.header.connection.5">8.8</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.1</a>, <a class="iref" href="#rfc.xref.header.connection.7">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.4</a></li> 2756 2796 <li class="indline1">content negotiation <a class="iref" href="#rfc.iref.c.4">C</a></li> 2757 <li class="indline1">Content-Length header <a class="iref" href="#rfc.xref.header.content-length.1"> 3.4</a>, <a class="iref" href="#rfc.iref.c.2"><b>7.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">8.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li>2797 <li class="indline1">Content-Length header <a class="iref" href="#rfc.xref.header.content-length.1">4.4</a>, <a class="iref" href="#rfc.iref.c.2"><b>8.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">9.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li> 2758 2798 </ul> 2759 2799 </li> 2760 2800 <li class="indline0"><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul class="ind"> 2761 <li class="indline1">Date header <a class="iref" href="#rfc.xref.header.date.1"> 3.5</a>, <a class="iref" href="#rfc.iref.d.1"><b>7.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">8.1</a></li>2801 <li class="indline1">Date header <a class="iref" href="#rfc.xref.header.date.1">4.5</a>, <a class="iref" href="#rfc.iref.d.1"><b>8.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">9.1</a></li> 2762 2802 <li class="indline1">downstream <a class="iref" href="#rfc.iref.d.2">C</a></li> 2763 2803 </ul> … … 2768 2808 </li> 2769 2809 <li class="indline0"><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul class="ind"> 2770 <li class="indline1">gateway <a class="iref" href="#rfc.iref.g.1 10">C</a></li>2810 <li class="indline1">gateway <a class="iref" href="#rfc.iref.g.108">C</a></li> 2771 2811 <li class="indline1"><tt>Grammar</tt> 2772 2812 <ul class="ind"> 2773 <li class="indline1"><tt>absolute-URI</tt> <a class="iref" href="#rfc.iref.g.2 9"><b>2.2</b></a></li>2813 <li class="indline1"><tt>absolute-URI</tt> <a class="iref" href="#rfc.iref.g.27"><b>2.1</b></a></li> 2774 2814 <li class="indline1">ALPHA <a class="iref" href="#rfc.iref.g.1"><b>1.2</b></a></li> 2775 <li class="indline1"><tt>asctime-date</tt> <a class="iref" href="#rfc.iref.g.4 2"><b>2.3.1</b></a></li>2776 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g.5 3"><b>2.4</b></a></li>2777 <li class="indline1"><tt>authority</tt> <a class="iref" href="#rfc.iref.g. 30"><b>2.2</b></a></li>2815 <li class="indline1"><tt>asctime-date</tt> <a class="iref" href="#rfc.iref.g.40"><b>3.2.1</b></a></li> 2816 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g.51"><b>3.3</b></a></li> 2817 <li class="indline1"><tt>authority</tt> <a class="iref" href="#rfc.iref.g.28"><b>2.1</b></a></li> 2778 2818 <li class="indline1"><tt>BWS</tt> <a class="iref" href="#rfc.iref.g.16"><b>1.2.2</b></a></li> 2779 2819 <li class="indline1">CHAR <a class="iref" href="#rfc.iref.g.2"><b>1.2</b></a></li> 2780 <li class="indline1"><tt>chunk</tt> <a class="iref" href="#rfc.iref.g.5 6"><b>2.4.1</b></a></li>2781 <li class="indline1"><tt>chunk-data</tt> <a class="iref" href="#rfc.iref.g.6 2"><b>2.4.1</b></a></li>2782 <li class="indline1"><tt>chunk-ext</tt> <a class="iref" href="#rfc.iref.g.5 9"><b>2.4.1</b></a></li>2783 <li class="indline1"><tt>chunk-ext-name</tt> <a class="iref" href="#rfc.iref.g. 60"><b>2.4.1</b></a></li>2784 <li class="indline1"><tt>chunk-ext-val</tt> <a class="iref" href="#rfc.iref.g. 61"><b>2.4.1</b></a></li>2785 <li class="indline1"><tt>chunk-size</tt> <a class="iref" href="#rfc.iref.g.5 7"><b>2.4.1</b></a></li>2786 <li class="indline1"><tt>Chunked-Body</tt> <a class="iref" href="#rfc.iref.g.5 5"><b>2.4.1</b></a></li>2820 <li class="indline1"><tt>chunk</tt> <a class="iref" href="#rfc.iref.g.54"><b>3.3.1</b></a></li> 2821 <li class="indline1"><tt>chunk-data</tt> <a class="iref" href="#rfc.iref.g.60"><b>3.3.1</b></a></li> 2822 <li class="indline1"><tt>chunk-ext</tt> <a class="iref" href="#rfc.iref.g.57"><b>3.3.1</b></a></li> 2823 <li class="indline1"><tt>chunk-ext-name</tt> <a class="iref" href="#rfc.iref.g.58"><b>3.3.1</b></a></li> 2824 <li class="indline1"><tt>chunk-ext-val</tt> <a class="iref" href="#rfc.iref.g.59"><b>3.3.1</b></a></li> 2825 <li class="indline1"><tt>chunk-size</tt> <a class="iref" href="#rfc.iref.g.55"><b>3.3.1</b></a></li> 2826 <li class="indline1"><tt>Chunked-Body</tt> <a class="iref" href="#rfc.iref.g.53"><b>3.3.1</b></a></li> 2787 2827 <li class="indline1"><tt>comment</tt> <a class="iref" href="#rfc.iref.g.20"><b>1.2.2</b></a></li> 2788 <li class="indline1"><tt>Connection</tt> <a class="iref" href="#rfc.iref.g.8 5"><b>7.1</b></a></li>2789 <li class="indline1"><tt>connection-token</tt> <a class="iref" href="#rfc.iref.g.8 7"><b>7.1</b></a></li>2790 <li class="indline1"><tt>Connection-v</tt> <a class="iref" href="#rfc.iref.g.8 6"><b>7.1</b></a></li>2791 <li class="indline1"><tt>Content-Length</tt> <a class="iref" href="#rfc.iref.g.8 8"><b>7.2</b></a></li>2792 <li class="indline1"><tt>Content-Length-v</tt> <a class="iref" href="#rfc.iref.g.8 9"><b>7.2</b></a></li>2828 <li class="indline1"><tt>Connection</tt> <a class="iref" href="#rfc.iref.g.83"><b>8.1</b></a></li> 2829 <li class="indline1"><tt>connection-token</tt> <a class="iref" href="#rfc.iref.g.85"><b>8.1</b></a></li> 2830 <li class="indline1"><tt>Connection-v</tt> <a class="iref" href="#rfc.iref.g.84"><b>8.1</b></a></li> 2831 <li class="indline1"><tt>Content-Length</tt> <a class="iref" href="#rfc.iref.g.86"><b>8.2</b></a></li> 2832 <li class="indline1"><tt>Content-Length-v</tt> <a class="iref" href="#rfc.iref.g.87"><b>8.2</b></a></li> 2793 2833 <li class="indline1">CR <a class="iref" href="#rfc.iref.g.3"><b>1.2</b></a></li> 2794 2834 <li class="indline1">CRLF <a class="iref" href="#rfc.iref.g.4"><b>1.2</b></a></li> 2795 2835 <li class="indline1"><tt>ctext</tt> <a class="iref" href="#rfc.iref.g.21"><b>1.2.2</b></a></li> 2796 2836 <li class="indline1">CTL <a class="iref" href="#rfc.iref.g.5"><b>1.2</b></a></li> 2797 <li class="indline1"><tt>Date</tt> <a class="iref" href="#rfc.iref.g. 90"><b>7.3</b></a></li>2798 <li class="indline1"><tt>Date-v</tt> <a class="iref" href="#rfc.iref.g. 91"><b>7.3</b></a></li>2799 <li class="indline1"><tt>date1</tt> <a class="iref" href="#rfc.iref.g.4 3"><b>2.3.1</b></a></li>2800 <li class="indline1"><tt>date2</tt> <a class="iref" href="#rfc.iref.g.4 4"><b>2.3.1</b></a></li>2801 <li class="indline1"><tt>date3</tt> <a class="iref" href="#rfc.iref.g.4 5"><b>2.3.1</b></a></li>2837 <li class="indline1"><tt>Date</tt> <a class="iref" href="#rfc.iref.g.88"><b>8.3</b></a></li> 2838 <li class="indline1"><tt>Date-v</tt> <a class="iref" href="#rfc.iref.g.89"><b>8.3</b></a></li> 2839 <li class="indline1"><tt>date1</tt> <a class="iref" href="#rfc.iref.g.41"><b>3.2.1</b></a></li> 2840 <li class="indline1"><tt>date2</tt> <a class="iref" href="#rfc.iref.g.42"><b>3.2.1</b></a></li> 2841 <li class="indline1"><tt>date3</tt> <a class="iref" href="#rfc.iref.g.43"><b>3.2.1</b></a></li> 2802 2842 <li class="indline1">DIGIT <a class="iref" href="#rfc.iref.g.6"><b>1.2</b></a></li> 2803 2843 <li class="indline1">DQUOTE <a class="iref" href="#rfc.iref.g.7"><b>1.2</b></a></li> 2804 <li class="indline1"><tt>extension-code</tt> <a class="iref" href="#rfc.iref.g.8 3"><b>5.1.1</b></a></li>2805 <li class="indline1"><tt>extension-method</tt> <a class="iref" href="#rfc.iref.g.7 8"><b>4.1.1</b></a></li>2806 <li class="indline1"><tt>field-content</tt> <a class="iref" href="#rfc.iref.g.7 2"><b>3.2</b></a></li>2807 <li class="indline1"><tt>field-name</tt> <a class="iref" href="#rfc.iref.g. 70"><b>3.2</b></a></li>2808 <li class="indline1"><tt>field-value</tt> <a class="iref" href="#rfc.iref.g. 71"><b>3.2</b></a></li>2809 <li class="indline1"><tt>general-header</tt> <a class="iref" href="#rfc.iref.g.7 4"><b>3.5</b></a></li>2810 <li class="indline1"><tt>generic-message</tt> <a class="iref" href="#rfc.iref.g.6 7"><b>3.1</b></a></li>2844 <li class="indline1"><tt>extension-code</tt> <a class="iref" href="#rfc.iref.g.81"><b>6.1.1</b></a></li> 2845 <li class="indline1"><tt>extension-method</tt> <a class="iref" href="#rfc.iref.g.76"><b>5.1.1</b></a></li> 2846 <li class="indline1"><tt>field-content</tt> <a class="iref" href="#rfc.iref.g.70"><b>4.2</b></a></li> 2847 <li class="indline1"><tt>field-name</tt> <a class="iref" href="#rfc.iref.g.68"><b>4.2</b></a></li> 2848 <li class="indline1"><tt>field-value</tt> <a class="iref" href="#rfc.iref.g.69"><b>4.2</b></a></li> 2849 <li class="indline1"><tt>general-header</tt> <a class="iref" href="#rfc.iref.g.72"><b>4.5</b></a></li> 2850 <li class="indline1"><tt>generic-message</tt> <a class="iref" href="#rfc.iref.g.65"><b>4.1</b></a></li> 2811 2851 <li class="indline1">HEXDIG <a class="iref" href="#rfc.iref.g.8"><b>1.2</b></a></li> 2812 <li class="indline1"><tt>Host</tt> <a class="iref" href="#rfc.iref.g.9 2"><b>7.4</b></a></li>2813 <li class="indline1"><tt>Host-v</tt> <a class="iref" href="#rfc.iref.g.9 3"><b>7.4</b></a></li>2852 <li class="indline1"><tt>Host</tt> <a class="iref" href="#rfc.iref.g.90"><b>8.4</b></a></li> 2853 <li class="indline1"><tt>Host-v</tt> <a class="iref" href="#rfc.iref.g.91"><b>8.4</b></a></li> 2814 2854 <li class="indline1">HTAB <a class="iref" href="#rfc.iref.g.9"><b>1.2</b></a></li> 2815 <li class="indline1"><tt>HTTP-date</tt> <a class="iref" href="#rfc.iref.g.3 8"><b>2.3.1</b></a></li>2816 <li class="indline1"><tt>HTTP-message</tt> <a class="iref" href="#rfc.iref.g.6 6"><b>3.1</b></a></li>2817 <li class="indline1"><tt>HTTP-Prot-Name</tt> <a class="iref" href="#rfc.iref.g. 27"><b>2.1</b></a></li>2818 <li class="indline1"><tt>http-URI</tt> <a class="iref" href="#rfc.iref.g.3 7"><b>2.2.1</b></a></li>2819 <li class="indline1"><tt>HTTP-Version</tt> <a class="iref" href="#rfc.iref.g. 26"><b>2.1</b></a></li>2820 <li class="indline1"><tt>last-chunk</tt> <a class="iref" href="#rfc.iref.g.5 8"><b>2.4.1</b></a></li>2855 <li class="indline1"><tt>HTTP-date</tt> <a class="iref" href="#rfc.iref.g.36"><b>3.2.1</b></a></li> 2856 <li class="indline1"><tt>HTTP-message</tt> <a class="iref" href="#rfc.iref.g.64"><b>4.1</b></a></li> 2857 <li class="indline1"><tt>HTTP-Prot-Name</tt> <a class="iref" href="#rfc.iref.g.35"><b>3.1</b></a></li> 2858 <li class="indline1"><tt>http-URI</tt> <a class="iref" href="#rfc.iref.g.33"><b>2.1.1</b></a></li> 2859 <li class="indline1"><tt>HTTP-Version</tt> <a class="iref" href="#rfc.iref.g.34"><b>3.1</b></a></li> 2860 <li class="indline1"><tt>last-chunk</tt> <a class="iref" href="#rfc.iref.g.56"><b>3.3.1</b></a></li> 2821 2861 <li class="indline1">LF <a class="iref" href="#rfc.iref.g.10"><b>1.2</b></a></li> 2822 <li class="indline1"><tt>message-body</tt> <a class="iref" href="#rfc.iref.g.7 3"><b>3.3</b></a></li>2823 <li class="indline1"><tt>message-header</tt> <a class="iref" href="#rfc.iref.g.6 9"><b>3.2</b></a></li>2824 <li class="indline1"><tt>Method</tt> <a class="iref" href="#rfc.iref.g.7 7"><b>4.1.1</b></a></li>2825 <li class="indline1"><tt>month</tt> <a class="iref" href="#rfc.iref.g.4 9"><b>2.3.1</b></a></li>2826 <li class="indline1"><tt>obsolete-date</tt> <a class="iref" href="#rfc.iref.g. 40"><b>2.3.1</b></a></li>2862 <li class="indline1"><tt>message-body</tt> <a class="iref" href="#rfc.iref.g.71"><b>4.3</b></a></li> 2863 <li class="indline1"><tt>message-header</tt> <a class="iref" href="#rfc.iref.g.67"><b>4.2</b></a></li> 2864 <li class="indline1"><tt>Method</tt> <a class="iref" href="#rfc.iref.g.75"><b>5.1.1</b></a></li> 2865 <li class="indline1"><tt>month</tt> <a class="iref" href="#rfc.iref.g.47"><b>3.2.1</b></a></li> 2866 <li class="indline1"><tt>obsolete-date</tt> <a class="iref" href="#rfc.iref.g.38"><b>3.2.1</b></a></li> 2827 2867 <li class="indline1">OCTET <a class="iref" href="#rfc.iref.g.11"><b>1.2</b></a></li> 2828 2868 <li class="indline1"><tt>OWS</tt> <a class="iref" href="#rfc.iref.g.14"><b>1.2.2</b></a></li> 2829 <li class="indline1"><tt>parameter</tt> <a class="iref" href="#rfc.iref.g.5 2"><b>2.4</b></a></li>2830 <li class="indline1"><tt>path-absolute</tt> <a class="iref" href="#rfc.iref.g. 31"><b>2.2</b></a></li>2831 <li class="indline1"><tt>port</tt> <a class="iref" href="#rfc.iref.g.3 2"><b>2.2</b></a></li>2832 <li class="indline1"><tt>product</tt> <a class="iref" href="#rfc.iref.g.6 4"><b>2.5</b></a></li>2833 <li class="indline1"><tt>product-version</tt> <a class="iref" href="#rfc.iref.g.6 5"><b>2.5</b></a></li>2834 <li class="indline1"><tt>protocol-name</tt> <a class="iref" href="#rfc.iref.g.10 6"><b>7.9</b></a></li>2835 <li class="indline1"><tt>protocol-version</tt> <a class="iref" href="#rfc.iref.g.10 7"><b>7.9</b></a></li>2836 <li class="indline1"><tt>pseudonym</tt> <a class="iref" href="#rfc.iref.g.10 9"><b>7.9</b></a></li>2869 <li class="indline1"><tt>parameter</tt> <a class="iref" href="#rfc.iref.g.50"><b>3.3</b></a></li> 2870 <li class="indline1"><tt>path-absolute</tt> <a class="iref" href="#rfc.iref.g.29"><b>2.1</b></a></li> 2871 <li class="indline1"><tt>port</tt> <a class="iref" href="#rfc.iref.g.30"><b>2.1</b></a></li> 2872 <li class="indline1"><tt>product</tt> <a class="iref" href="#rfc.iref.g.62"><b>3.4</b></a></li> 2873 <li class="indline1"><tt>product-version</tt> <a class="iref" href="#rfc.iref.g.63"><b>3.4</b></a></li> 2874 <li class="indline1"><tt>protocol-name</tt> <a class="iref" href="#rfc.iref.g.104"><b>8.9</b></a></li> 2875 <li class="indline1"><tt>protocol-version</tt> <a class="iref" href="#rfc.iref.g.105"><b>8.9</b></a></li> 2876 <li class="indline1"><tt>pseudonym</tt> <a class="iref" href="#rfc.iref.g.107"><b>8.9</b></a></li> 2837 2877 <li class="indline1"><tt>qdtext</tt> <a class="iref" href="#rfc.iref.g.23"><b>1.2.2</b></a></li> 2838 <li class="indline1"><tt>query</tt> <a class="iref" href="#rfc.iref.g.3 3"><b>2.2</b></a></li>2878 <li class="indline1"><tt>query</tt> <a class="iref" href="#rfc.iref.g.31"><b>2.1</b></a></li> 2839 2879 <li class="indline1"><tt>quoted-pair</tt> <a class="iref" href="#rfc.iref.g.25"><b>1.2.2</b></a></li> 2840 2880 <li class="indline1"><tt>quoted-string</tt> <a class="iref" href="#rfc.iref.g.22"><b>1.2.2</b></a></li> 2841 2881 <li class="indline1"><tt>quoted-text</tt> <a class="iref" href="#rfc.iref.g.24"><b>1.2.2</b></a></li> 2842 <li class="indline1"><tt>Reason-Phrase</tt> <a class="iref" href="#rfc.iref.g.84"><b>5.1.1</b></a></li> 2843 <li class="indline1"><tt>received-by</tt> <a class="iref" href="#rfc.iref.g.108"><b>7.9</b></a></li> 2844 <li class="indline1"><tt>received-protocol</tt> <a class="iref" href="#rfc.iref.g.105"><b>7.9</b></a></li> 2845 <li class="indline1"><tt>relative-part</tt> <a class="iref" href="#rfc.iref.g.36"><b>2.2</b></a></li> 2846 <li class="indline1"><tt>relativeURI</tt> <a class="iref" href="#rfc.iref.g.35"><b>2.2</b></a></li> 2847 <li class="indline1"><tt>Request</tt> <a class="iref" href="#rfc.iref.g.75"><b>4</b></a></li> 2848 <li class="indline1"><tt>Request-Line</tt> <a class="iref" href="#rfc.iref.g.76"><b>4.1</b></a></li> 2849 <li class="indline1"><tt>Request-URI</tt> <a class="iref" href="#rfc.iref.g.79"><b>4.1.2</b></a></li> 2850 <li class="indline1"><tt>Response</tt> <a class="iref" href="#rfc.iref.g.80"><b>5</b></a></li> 2851 <li class="indline1"><tt>rfc1123-date</tt> <a class="iref" href="#rfc.iref.g.39"><b>2.3.1</b></a></li> 2852 <li class="indline1"><tt>rfc850-date</tt> <a class="iref" href="#rfc.iref.g.41"><b>2.3.1</b></a></li> 2882 <li class="indline1"><tt>Reason-Phrase</tt> <a class="iref" href="#rfc.iref.g.82"><b>6.1.1</b></a></li> 2883 <li class="indline1"><tt>received-by</tt> <a class="iref" href="#rfc.iref.g.106"><b>8.9</b></a></li> 2884 <li class="indline1"><tt>received-protocol</tt> <a class="iref" href="#rfc.iref.g.103"><b>8.9</b></a></li> 2885 <li class="indline1"><tt>Request</tt> <a class="iref" href="#rfc.iref.g.73"><b>5</b></a></li> 2886 <li class="indline1"><tt>Request-Line</tt> <a class="iref" href="#rfc.iref.g.74"><b>5.1</b></a></li> 2887 <li class="indline1"><tt>request-target</tt> <a class="iref" href="#rfc.iref.g.77"><b>5.1.2</b></a></li> 2888 <li class="indline1"><tt>Response</tt> <a class="iref" href="#rfc.iref.g.78"><b>6</b></a></li> 2889 <li class="indline1"><tt>rfc1123-date</tt> <a class="iref" href="#rfc.iref.g.37"><b>3.2.1</b></a></li> 2890 <li class="indline1"><tt>rfc850-date</tt> <a class="iref" href="#rfc.iref.g.39"><b>3.2.1</b></a></li> 2853 2891 <li class="indline1"><tt>RWS</tt> <a class="iref" href="#rfc.iref.g.15"><b>1.2.2</b></a></li> 2854 2892 <li class="indline1">SP <a class="iref" href="#rfc.iref.g.12"><b>1.2</b></a></li> 2855 <li class="indline1"><tt>start-line</tt> <a class="iref" href="#rfc.iref.g.6 8"><b>3.1</b></a></li>2856 <li class="indline1"><tt>Status-Code</tt> <a class="iref" href="#rfc.iref.g.8 2"><b>5.1.1</b></a></li>2857 <li class="indline1"><tt>Status-Line</tt> <a class="iref" href="#rfc.iref.g. 81"><b>5.1</b></a></li>2858 <li class="indline1"><tt>t-codings</tt> <a class="iref" href="#rfc.iref.g.9 6"><b>7.5</b></a></li>2893 <li class="indline1"><tt>start-line</tt> <a class="iref" href="#rfc.iref.g.66"><b>4.1</b></a></li> 2894 <li class="indline1"><tt>Status-Code</tt> <a class="iref" href="#rfc.iref.g.80"><b>6.1.1</b></a></li> 2895 <li class="indline1"><tt>Status-Line</tt> <a class="iref" href="#rfc.iref.g.79"><b>6.1</b></a></li> 2896 <li class="indline1"><tt>t-codings</tt> <a class="iref" href="#rfc.iref.g.94"><b>8.5</b></a></li> 2859 2897 <li class="indline1"><tt>tchar</tt> <a class="iref" href="#rfc.iref.g.19"><b>1.2.2</b></a></li> 2860 <li class="indline1"><tt>TE</tt> <a class="iref" href="#rfc.iref.g.9 4"><b>7.5</b></a></li>2861 <li class="indline1"><tt>TE-v</tt> <a class="iref" href="#rfc.iref.g.9 5"><b>7.5</b></a></li>2898 <li class="indline1"><tt>TE</tt> <a class="iref" href="#rfc.iref.g.92"><b>8.5</b></a></li> 2899 <li class="indline1"><tt>TE-v</tt> <a class="iref" href="#rfc.iref.g.93"><b>8.5</b></a></li> 2862 2900 <li class="indline1"><tt>TEXT</tt> <a class="iref" href="#rfc.iref.g.17"><b>1.2.2</b></a></li> 2863 <li class="indline1"><tt>time</tt> <a class="iref" href="#rfc.iref.g.4 6"><b>2.3.1</b></a></li>2901 <li class="indline1"><tt>time</tt> <a class="iref" href="#rfc.iref.g.44"><b>3.2.1</b></a></li> 2864 2902 <li class="indline1"><tt>token</tt> <a class="iref" href="#rfc.iref.g.18"><b>1.2.2</b></a></li> 2865 <li class="indline1"><tt>Trailer</tt> <a class="iref" href="#rfc.iref.g.9 7"><b>7.6</b></a></li>2866 <li class="indline1"><tt>trailer-part</tt> <a class="iref" href="#rfc.iref.g.6 3"><b>2.4.1</b></a></li>2867 <li class="indline1"><tt>Trailer-v</tt> <a class="iref" href="#rfc.iref.g.9 8"><b>7.6</b></a></li>2868 <li class="indline1"><tt>transfer-coding</tt> <a class="iref" href="#rfc.iref.g. 50"><b>2.4</b></a></li>2869 <li class="indline1"><tt>Transfer-Encoding</tt> <a class="iref" href="#rfc.iref.g.9 9"><b>7.7</b></a></li>2870 <li class="indline1"><tt>Transfer-Encoding-v</tt> <a class="iref" href="#rfc.iref.g. 100"><b>7.7</b></a></li>2871 <li class="indline1"><tt>transfer-extension</tt> <a class="iref" href="#rfc.iref.g. 51"><b>2.4</b></a></li>2872 <li class="indline1"><tt>Upgrade</tt> <a class="iref" href="#rfc.iref.g. 101"><b>7.8</b></a></li>2873 <li class="indline1"><tt>Upgrade-v</tt> <a class="iref" href="#rfc.iref.g.10 2"><b>7.8</b></a></li>2874 <li class="indline1"><tt>uri-host</tt> <a class="iref" href="#rfc.iref.g.3 4"><b>2.2</b></a></li>2875 <li class="indline1"><tt>URI-reference</tt> <a class="iref" href="#rfc.iref.g.2 8"><b>2.2</b></a></li>2876 <li class="indline1"><tt>value</tt> <a class="iref" href="#rfc.iref.g.5 4"><b>2.4</b></a></li>2877 <li class="indline1"><tt>Via</tt> <a class="iref" href="#rfc.iref.g.10 3"><b>7.9</b></a></li>2878 <li class="indline1"><tt>Via-v</tt> <a class="iref" href="#rfc.iref.g.10 4"><b>7.9</b></a></li>2879 <li class="indline1"><tt>weekday</tt> <a class="iref" href="#rfc.iref.g.4 8"><b>2.3.1</b></a></li>2880 <li class="indline1"><tt>wkday</tt> <a class="iref" href="#rfc.iref.g.4 7"><b>2.3.1</b></a></li>2903 <li class="indline1"><tt>Trailer</tt> <a class="iref" href="#rfc.iref.g.95"><b>8.6</b></a></li> 2904 <li class="indline1"><tt>trailer-part</tt> <a class="iref" href="#rfc.iref.g.61"><b>3.3.1</b></a></li> 2905 <li class="indline1"><tt>Trailer-v</tt> <a class="iref" href="#rfc.iref.g.96"><b>8.6</b></a></li> 2906 <li class="indline1"><tt>transfer-coding</tt> <a class="iref" href="#rfc.iref.g.48"><b>3.3</b></a></li> 2907 <li class="indline1"><tt>Transfer-Encoding</tt> <a class="iref" href="#rfc.iref.g.97"><b>8.7</b></a></li> 2908 <li class="indline1"><tt>Transfer-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.98"><b>8.7</b></a></li> 2909 <li class="indline1"><tt>transfer-extension</tt> <a class="iref" href="#rfc.iref.g.49"><b>3.3</b></a></li> 2910 <li class="indline1"><tt>Upgrade</tt> <a class="iref" href="#rfc.iref.g.99"><b>8.8</b></a></li> 2911 <li class="indline1"><tt>Upgrade-v</tt> <a class="iref" href="#rfc.iref.g.100"><b>8.8</b></a></li> 2912 <li class="indline1"><tt>uri-host</tt> <a class="iref" href="#rfc.iref.g.32"><b>2.1</b></a></li> 2913 <li class="indline1"><tt>URI-reference</tt> <a class="iref" href="#rfc.iref.g.26"><b>2.1</b></a></li> 2914 <li class="indline1"><tt>value</tt> <a class="iref" href="#rfc.iref.g.52"><b>3.3</b></a></li> 2915 <li class="indline1"><tt>Via</tt> <a class="iref" href="#rfc.iref.g.101"><b>8.9</b></a></li> 2916 <li class="indline1"><tt>Via-v</tt> <a class="iref" href="#rfc.iref.g.102"><b>8.9</b></a></li> 2917 <li class="indline1"><tt>weekday</tt> <a class="iref" href="#rfc.iref.g.46"><b>3.2.1</b></a></li> 2918 <li class="indline1"><tt>wkday</tt> <a class="iref" href="#rfc.iref.g.45"><b>3.2.1</b></a></li> 2881 2919 <li class="indline1">WSP <a class="iref" href="#rfc.iref.g.13"><b>1.2</b></a></li> 2882 2920 </ul> … … 2887 2925 <li class="indline1">Headers 2888 2926 <ul class="ind"> 2889 <li class="indline1">Connection <a class="iref" href="#rfc.xref.header.connection.1"> 3.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">6.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">6.1.3</a>, <a class="iref" href="#rfc.iref.h.3"><b>7.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.4">7.5</a>, <a class="iref" href="#rfc.xref.header.connection.5">7.8</a>, <a class="iref" href="#rfc.xref.header.connection.6">8.1</a>, <a class="iref" href="#rfc.xref.header.connection.7">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.4</a></li>2890 <li class="indline1">Content-Length <a class="iref" href="#rfc.xref.header.content-length.1"> 3.4</a>, <a class="iref" href="#rfc.iref.h.4"><b>7.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">8.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li>2891 <li class="indline1">Date <a class="iref" href="#rfc.xref.header.date.1"> 3.5</a>, <a class="iref" href="#rfc.iref.h.5"><b>7.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">8.1</a></li>2892 <li class="indline1">Host <a class="iref" href="#rfc.iref.h.7"><b> 7.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">8.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li>2893 <li class="indline1">TE <a class="iref" href="#rfc.xref.header.te.1"> 2.4</a>, <a class="iref" href="#rfc.xref.header.te.2">2.4.1</a>, <a class="iref" href="#rfc.iref.h.8"><b>7.5</b></a>, <a class="iref" href="#rfc.xref.header.te.3">8.1</a>, <a class="iref" href="#rfc.xref.header.te.4">B.3</a></li>2894 <li class="indline1">Trailer <a class="iref" href="#rfc.xref.header.trailer.1"> 2.4.1</a>, <a class="iref" href="#rfc.xref.header.trailer.2">3.5</a>, <a class="iref" href="#rfc.iref.h.9"><b>7.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">8.1</a></li>2895 <li class="indline1">Transfer-Encoding <a class="iref" href="#rfc.xref.header.transfer-encoding.1"> 2.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">3.5</a>, <a class="iref" href="#rfc.iref.h.10"><b>7.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">8.1</a></li>2896 <li class="indline1">Upgrade <a class="iref" href="#rfc.xref.header.upgrade.1"> 3.5</a>, <a class="iref" href="#rfc.iref.h.11"><b>7.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">8.1</a></li>2897 <li class="indline1">Via <a class="iref" href="#rfc.xref.header.via.1"> 3.5</a>, <a class="iref" href="#rfc.iref.h.12"><b>7.9</b></a>, <a class="iref" href="#rfc.xref.header.via.2">8.1</a></li>2927 <li class="indline1">Connection <a class="iref" href="#rfc.xref.header.connection.1">4.5</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.iref.h.3"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.4">8.5</a>, <a class="iref" href="#rfc.xref.header.connection.5">8.8</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.1</a>, <a class="iref" href="#rfc.xref.header.connection.7">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.4</a></li> 2928 <li class="indline1">Content-Length <a class="iref" href="#rfc.xref.header.content-length.1">4.4</a>, <a class="iref" href="#rfc.iref.h.4"><b>8.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">9.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li> 2929 <li class="indline1">Date <a class="iref" href="#rfc.xref.header.date.1">4.5</a>, <a class="iref" href="#rfc.iref.h.5"><b>8.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">9.1</a></li> 2930 <li class="indline1">Host <a class="iref" href="#rfc.iref.h.7"><b>8.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">9.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li> 2931 <li class="indline1">TE <a class="iref" href="#rfc.xref.header.te.1">3.3</a>, <a class="iref" href="#rfc.xref.header.te.2">3.3.1</a>, <a class="iref" href="#rfc.iref.h.8"><b>8.5</b></a>, <a class="iref" href="#rfc.xref.header.te.3">9.1</a>, <a class="iref" href="#rfc.xref.header.te.4">B.3</a></li> 2932 <li class="indline1">Trailer <a class="iref" href="#rfc.xref.header.trailer.1">3.3.1</a>, <a class="iref" href="#rfc.xref.header.trailer.2">4.5</a>, <a class="iref" href="#rfc.iref.h.9"><b>8.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">9.1</a></li> 2933 <li class="indline1">Transfer-Encoding <a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">4.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">4.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">4.5</a>, <a class="iref" href="#rfc.iref.h.10"><b>8.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">9.1</a></li> 2934 <li class="indline1">Upgrade <a class="iref" href="#rfc.xref.header.upgrade.1">4.5</a>, <a class="iref" href="#rfc.iref.h.11"><b>8.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">9.1</a></li> 2935 <li class="indline1">Via <a class="iref" href="#rfc.xref.header.via.1">4.5</a>, <a class="iref" href="#rfc.iref.h.12"><b>8.9</b></a>, <a class="iref" href="#rfc.xref.header.via.2">9.1</a></li> 2898 2936 </ul> 2899 2937 </li> 2900 <li class="indline1">Host header <a class="iref" href="#rfc.iref.h.6"><b> 7.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">8.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li>2901 <li class="indline1">http URI scheme <a class="iref" href="#rfc.iref.h.1"><b>2. 2.1</b></a></li>2902 <li class="indline1">https URI scheme <a class="iref" href="#rfc.iref.h.2">2. 2.1</a></li>2938 <li class="indline1">Host header <a class="iref" href="#rfc.iref.h.6"><b>8.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">9.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li> 2939 <li class="indline1">http URI scheme <a class="iref" href="#rfc.iref.h.1"><b>2.1.1</b></a></li> 2940 <li class="indline1">https URI scheme <a class="iref" href="#rfc.iref.h.2">2.1.1</a></li> 2903 2941 </ul> 2904 2942 </li> 2905 2943 <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind"> 2906 2944 <li class="indline1">inbound <a class="iref" href="#rfc.iref.i.1">C</a></li> 2907 <li class="indline1"><em>ISO-8859-1</em> <a class="iref" href="#rfc.xref.ISO-8859-1.1">1.2.2</a>, <a class="iref" href="#ISO-8859-1"><b>1 1.1</b></a></li>2945 <li class="indline1"><em>ISO-8859-1</em> <a class="iref" href="#rfc.xref.ISO-8859-1.1">1.2.2</a>, <a class="iref" href="#ISO-8859-1"><b>12.1</b></a></li> 2908 2946 </ul> 2909 2947 </li> 2910 2948 <li class="indline0"><a id="rfc.index.K" href="#rfc.index.K"><b>K</b></a><ul class="ind"> 2911 <li class="indline1"><em>Kri2001</em> <a class="iref" href="#rfc.xref.Kri2001.1"> 3.2</a>, <a class="iref" href="#Kri2001"><b>11.2</b></a></li>2949 <li class="indline1"><em>Kri2001</em> <a class="iref" href="#rfc.xref.Kri2001.1">4.2</a>, <a class="iref" href="#Kri2001"><b>12.2</b></a></li> 2912 2950 </ul> 2913 2951 </li> … … 2915 2953 <li class="indline1">Media Type 2916 2954 <ul class="ind"> 2917 <li class="indline1">application/http <a class="iref" href="#rfc.iref.m.3"><b> 8.3.2</b></a></li>2918 <li class="indline1">message/http <a class="iref" href="#rfc.iref.m.1"><b> 8.3.1</b></a></li>2955 <li class="indline1">application/http <a class="iref" href="#rfc.iref.m.3"><b>9.3.2</b></a></li> 2956 <li class="indline1">message/http <a class="iref" href="#rfc.iref.m.1"><b>9.3.1</b></a></li> 2919 2957 </ul> 2920 2958 </li> 2921 2959 <li class="indline1">message <a class="iref" href="#rfc.iref.m.4">C</a></li> 2922 <li class="indline1">message/http Media Type <a class="iref" href="#rfc.iref.m.2"><b> 8.3.1</b></a></li>2960 <li class="indline1">message/http Media Type <a class="iref" href="#rfc.iref.m.2"><b>9.3.1</b></a></li> 2923 2961 </ul> 2924 2962 </li> 2925 2963 <li class="indline0"><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul class="ind"> 2926 <li class="indline1"><em>Nie1997</em> <a class="iref" href="#rfc.xref.Nie1997.1"> 6.1.1</a>, <a class="iref" href="#Nie1997"><b>11.2</b></a>, <a class="iref" href="#rfc.xref.Nie1997.2">B.3</a></li>2964 <li class="indline1"><em>Nie1997</em> <a class="iref" href="#rfc.xref.Nie1997.1">7.1.1</a>, <a class="iref" href="#Nie1997"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.Nie1997.2">B.3</a></li> 2927 2965 </ul> 2928 2966 </li> … … 2933 2971 </li> 2934 2972 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2935 <li class="indline1"><em>Pad1995</em> <a class="iref" href="#rfc.xref.Pad1995.1"> 6.1.1</a>, <a class="iref" href="#Pad1995"><b>11.2</b></a></li>2936 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3"> 2.2</a>, <a class="iref" href="#rfc.xref.Part2.4">3.2</a>, <a class="iref" href="#rfc.xref.Part2.5">3.2</a>, <a class="iref" href="#rfc.xref.Part2.6">3.3</a>, <a class="iref" href="#rfc.xref.Part2.7">4</a>, <a class="iref" href="#rfc.xref.Part2.8">4.1.2</a>, <a class="iref" href="#rfc.xref.Part2.9">5</a>, <a class="iref" href="#rfc.xref.Part2.10">5.1.1</a>, <a class="iref" href="#rfc.xref.Part2.11">6.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">6.1.4</a>, <a class="iref" href="#rfc.xref.Part2.13">6.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">6.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">6.2.3</a>, <a class="iref" href="#rfc.xref.Part2.16">6.2.3</a>, <a class="iref" href="#Part2"><b>11.1</b></a><ul class="ind">2937 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part2. 6">3.3</a></li>2938 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2. 4">3.2</a>, <a class="iref" href="#rfc.xref.Part2.7">4</a></li>2939 <li class="indline1"><em>Section 6</em> <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2. 5">3.2</a>, <a class="iref" href="#rfc.xref.Part2.9">5</a></li>2940 <li class="indline1"><em>Section 8.1.2</em> <a class="iref" href="#rfc.xref.Part2.11"> 6.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">6.1.4</a></li>2941 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part2. 8">4.1.2</a></li>2942 <li class="indline1"><em>Section 9</em> <a class="iref" href="#rfc.xref.Part2.10"> 5.1.1</a></li>2943 <li class="indline1"><em>Section 9.1.1</em> <a class="iref" href="#rfc.xref.Part2.13"> 6.2.3</a></li>2944 <li class="indline1"><em>Section 9.1</em> <a class="iref" href="#rfc.xref.Part2.16"> 6.2.3</a></li>2945 <li class="indline1"><em>Section 9.4.15</em> <a class="iref" href="#rfc.xref.Part2. 3">2.2</a></li>2946 <li class="indline1"><em>Section 10.2</em> <a class="iref" href="#rfc.xref.Part2.14"> 6.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">6.2.3</a></li>2973 <li class="indline1"><em>Pad1995</em> <a class="iref" href="#rfc.xref.Pad1995.1">7.1.1</a>, <a class="iref" href="#Pad1995"><b>12.2</b></a></li> 2974 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.5">4.3</a>, <a class="iref" href="#rfc.xref.Part2.6">5</a>, <a class="iref" href="#rfc.xref.Part2.7">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.8">5.1.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a>, <a class="iref" href="#rfc.xref.Part2.10">6.1.1</a>, <a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.16">7.2.3</a>, <a class="iref" href="#Part2"><b>12.1</b></a><ul class="ind"> 2975 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part2.5">4.3</a></li> 2976 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4.2</a>, <a class="iref" href="#rfc.xref.Part2.6">5</a></li> 2977 <li class="indline1"><em>Section 6</em> <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.4">4.2</a>, <a class="iref" href="#rfc.xref.Part2.9">6</a></li> 2978 <li class="indline1"><em>Section 8.1.2</em> <a class="iref" href="#rfc.xref.Part2.11">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.12">7.1.4</a></li> 2979 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part2.7">5.1.2</a></li> 2980 <li class="indline1"><em>Section 9</em> <a class="iref" href="#rfc.xref.Part2.10">6.1.1</a></li> 2981 <li class="indline1"><em>Section 9.1.1</em> <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li> 2982 <li class="indline1"><em>Section 9.1</em> <a class="iref" href="#rfc.xref.Part2.16">7.2.3</a></li> 2983 <li class="indline1"><em>Section 9.4.15</em> <a class="iref" href="#rfc.xref.Part2.8">5.1.2</a></li> 2984 <li class="indline1"><em>Section 10.2</em> <a class="iref" href="#rfc.xref.Part2.14">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.15">7.2.3</a></li> 2947 2985 </ul> 2948 2986 </li> 2949 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.6"> 1.3</a>, <a class="iref" href="#rfc.xref.Part3.7">2.4</a>, <a class="iref" href="#rfc.xref.Part3.8">2.4</a>, <a class="iref" href="#rfc.xref.Part3.9">3.2</a>, <a class="iref" href="#rfc.xref.Part3.10">4</a>, <a class="iref" href="#rfc.xref.Part3.11">5</a>, <a class="iref" href="#rfc.xref.Part3.12">7.5</a>, <a class="iref" href="#Part3"><b>11.1</b></a>, <a class="iref" href="#rfc.xref.Part3.13">A</a>, <a class="iref" href="#rfc.xref.Part3.14">B.3</a>, <a class="iref" href="#rfc.xref.Part3.15">C</a>, <a class="iref" href="#rfc.xref.Part3.16">C</a>, <a class="iref" href="#rfc.xref.Part3.17">C</a><ul class="ind">2950 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part3. 7">2.4</a>, <a class="iref" href="#rfc.xref.Part3.8">2.4</a></li>2987 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.6">3.3</a>, <a class="iref" href="#rfc.xref.Part3.7">3.3</a>, <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a>, <a class="iref" href="#rfc.xref.Part3.11">8.5</a>, <a class="iref" href="#Part3"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part3.12">A</a>, <a class="iref" href="#rfc.xref.Part3.13">B.3</a>, <a class="iref" href="#rfc.xref.Part3.14">C</a>, <a class="iref" href="#rfc.xref.Part3.15">C</a>, <a class="iref" href="#rfc.xref.Part3.16">C</a><ul class="ind"> 2988 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part3.6">3.3</a>, <a class="iref" href="#rfc.xref.Part3.7">3.3</a></li> 2951 2989 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a></li> 2952 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part3.1 2">7.5</a></li>2953 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3. 9">3.2</a>, <a class="iref" href="#rfc.xref.Part3.10">4</a>, <a class="iref" href="#rfc.xref.Part3.11">5</a></li>2954 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.1 5">C</a></li>2990 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part3.11">8.5</a></li> 2991 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part3.5">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">4.2</a>, <a class="iref" href="#rfc.xref.Part3.9">5</a>, <a class="iref" href="#rfc.xref.Part3.10">6</a></li> 2992 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part3.14">C</a></li> 2955 2993 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a></li> 2956 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part3.1 6">C</a>, <a class="iref" href="#rfc.xref.Part3.17">C</a></li>2994 <li class="indline1"><em>Section 5</em> <a class="iref" href="#rfc.xref.Part3.15">C</a>, <a class="iref" href="#rfc.xref.Part3.16">C</a></li> 2957 2995 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a></li> 2958 <li class="indline1"><em>Appendix A</em> <a class="iref" href="#rfc.xref.Part3.1">1</a> , <a class="iref" href="#rfc.xref.Part3.6">1.3</a></li>2996 <li class="indline1"><em>Appendix A</em> <a class="iref" href="#rfc.xref.Part3.1">1</a></li> 2959 2997 </ul> 2960 2998 </li> 2961 <li class="indline1"><em>Part5</em> <a class="iref" href="#Part5"><b>1 1.1</b></a>, <a class="iref" href="#rfc.xref.Part5.1">B.3</a></li>2962 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.4"> 1.3</a>, <a class="iref" href="#rfc.xref.Part6.5">3.5</a>, <a class="iref" href="#rfc.xref.Part6.6">3.5</a>, <a class="iref" href="#rfc.xref.Part6.7">3.5</a>, <a class="iref" href="#Part6"><b>11.1</b></a>, <a class="iref" href="#rfc.xref.Part6.8">B.3</a>, <a class="iref" href="#rfc.xref.Part6.9">C</a><ul class="ind">2963 <li class="indline1"><em>Section 1</em> <a class="iref" href="#rfc.xref.Part6.4"> 1.3</a>, <a class="iref" href="#rfc.xref.Part6.9">C</a></li>2964 <li class="indline1"><em>Section 16.2</em> <a class="iref" href="#rfc.xref.Part6.5"> 3.5</a></li>2965 <li class="indline1"><em>Section 16.4</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.6"> 3.5</a></li>2966 <li class="indline1"><em>Section 16.6</em> <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.7"> 3.5</a></li>2999 <li class="indline1"><em>Part5</em> <a class="iref" href="#Part5"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part5.1">B.3</a></li> 3000 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.4">2.2</a>, <a class="iref" href="#rfc.xref.Part6.5">4.5</a>, <a class="iref" href="#rfc.xref.Part6.6">4.5</a>, <a class="iref" href="#rfc.xref.Part6.7">4.5</a>, <a class="iref" href="#Part6"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.Part6.8">B.3</a>, <a class="iref" href="#rfc.xref.Part6.9">C</a><ul class="ind"> 3001 <li class="indline1"><em>Section 1</em> <a class="iref" href="#rfc.xref.Part6.4">2.2</a>, <a class="iref" href="#rfc.xref.Part6.9">C</a></li> 3002 <li class="indline1"><em>Section 16.2</em> <a class="iref" href="#rfc.xref.Part6.5">4.5</a></li> 3003 <li class="indline1"><em>Section 16.4</em> <a class="iref" href="#rfc.xref.Part6.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.6">4.5</a></li> 3004 <li class="indline1"><em>Section 16.6</em> <a class="iref" href="#rfc.xref.Part6.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part6.7">4.5</a></li> 2967 3005 </ul> 2968 3006 </li> … … 2975 3013 <li class="indline1">resource <a class="iref" href="#rfc.iref.r.3">C</a></li> 2976 3014 <li class="indline1">response <a class="iref" href="#rfc.iref.r.2">C</a></li> 2977 <li class="indline1"><em>RFC1123</em> <a class="iref" href="#rfc.xref.RFC1123.1"> 2.3.1</a>, <a class="iref" href="#RFC1123"><b>11.2</b></a></li>2978 <li class="indline1"><em>RFC1305</em> <a class="iref" href="#rfc.xref.RFC1305.1"> 7.3</a>, <a class="iref" href="#RFC1305"><b>11.2</b></a></li>2979 <li class="indline1"><em>RFC1436</em> <a class="iref" href="#rfc.xref.RFC1436.1">1</a>, <a class="iref" href="#RFC1436"><b>1 1.2</b></a></li>2980 <li class="indline1"><em>RFC1900</em> <a class="iref" href="#rfc.xref.RFC1900.1">2. 2.1</a>, <a class="iref" href="#rfc.xref.RFC1900.2">9.4</a>, <a class="iref" href="#RFC1900"><b>11.2</b></a></li>2981 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#RFC1945"><b>1 1.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li>2982 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#rfc.xref.RFC2045.1">1</a>, <a class="iref" href="#rfc.xref.RFC2045.2"> 2.4</a>, <a class="iref" href="#rfc.xref.RFC2045.3">10</a>, <a class="iref" href="#RFC2045"><b>11.1</b></a></li>2983 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1">1.2.2</a>, <a class="iref" href="#RFC2047"><b>1 1.1</b></a></li>2984 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1"> 2.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">6.1.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">6.1.3</a>, <a class="iref" href="#rfc.xref.RFC2068.4">6.2.3</a>, <a class="iref" href="#rfc.xref.RFC2068.5">10</a>, <a class="iref" href="#RFC2068"><b>11.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.6">B</a>, <a class="iref" href="#rfc.xref.RFC2068.7">B.2</a><ul class="ind">3015 <li class="indline1"><em>RFC1123</em> <a class="iref" href="#rfc.xref.RFC1123.1">3.2.1</a>, <a class="iref" href="#RFC1123"><b>12.2</b></a></li> 3016 <li class="indline1"><em>RFC1305</em> <a class="iref" href="#rfc.xref.RFC1305.1">8.3</a>, <a class="iref" href="#RFC1305"><b>12.2</b></a></li> 3017 <li class="indline1"><em>RFC1436</em> <a class="iref" href="#rfc.xref.RFC1436.1">1</a>, <a class="iref" href="#RFC1436"><b>12.2</b></a></li> 3018 <li class="indline1"><em>RFC1900</em> <a class="iref" href="#rfc.xref.RFC1900.1">2.1.1</a>, <a class="iref" href="#rfc.xref.RFC1900.2">10.4</a>, <a class="iref" href="#RFC1900"><b>12.2</b></a></li> 3019 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#RFC1945"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li> 3020 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#rfc.xref.RFC2045.1">1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">3.3</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12.1</b></a></li> 3021 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1">1.2.2</a>, <a class="iref" href="#RFC2047"><b>12.1</b></a></li> 3022 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">7.1.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">7.1.3</a>, <a class="iref" href="#rfc.xref.RFC2068.4">7.2.3</a>, <a class="iref" href="#rfc.xref.RFC2068.5">11</a>, <a class="iref" href="#RFC2068"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.6">B</a>, <a class="iref" href="#rfc.xref.RFC2068.7">B.2</a><ul class="ind"> 2985 3023 <li class="indline1"><em>Section 19.7.1</em> <a class="iref" href="#rfc.xref.RFC2068.6">B</a></li> 2986 3024 </ul> 2987 3025 </li> 2988 <li class="indline1"><em>RFC2109</em> <a class="iref" href="#rfc.xref.RFC2109.1">3.2</a>, <a class="iref" href="#RFC2109"><b>11.2</b></a></li> 2989 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>11.1</b></a>, <a class="iref" href="#rfc.xref.RFC2119.2">B.3</a></li> 2990 <li class="indline1"><em>RFC2145</em> <a class="iref" href="#rfc.xref.RFC2145.1">2.1</a>, <a class="iref" href="#rfc.xref.RFC2145.2">2.1</a>, <a class="iref" href="#RFC2145"><b>11.2</b></a>, <a class="iref" href="#rfc.xref.RFC2145.3">B.3</a></li> 2991 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">10</a>, <a class="iref" href="#RFC2616"><b>11.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">D.1</a></li> 2992 <li class="indline1"><em>RFC2818</em> <a class="iref" href="#rfc.xref.RFC2818.1">2.2.1</a>, <a class="iref" href="#RFC2818"><b>11.2</b></a></li> 2993 <li class="indline1"><em>RFC2965</em> <a class="iref" href="#rfc.xref.RFC2965.1">3.2</a>, <a class="iref" href="#RFC2965"><b>11.2</b></a></li> 2994 <li class="indline1"><em>RFC3864</em> <a class="iref" href="#rfc.xref.RFC3864.1">8.1</a>, <a class="iref" href="#RFC3864"><b>11.2</b></a></li> 2995 <li class="indline1"><em>RFC3977</em> <a class="iref" href="#rfc.xref.RFC3977.1">1</a>, <a class="iref" href="#RFC3977"><b>11.2</b></a></li> 2996 <li class="indline1"><em>RFC3986</em> <a class="iref" href="#rfc.xref.RFC3986.1">1</a>, <a class="iref" href="#rfc.xref.RFC3986.2">2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.3">2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.4">2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.5">2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.6">2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.7">2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.8">2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.9">2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.10">2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.11">2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.12">2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.13">2.2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.14">4.1.2</a>, <a class="iref" href="#RFC3986"><b>11.1</b></a><ul class="ind"> 2997 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.RFC3986.13">2.2.2</a></li> 2998 <li class="indline1"><em>Section 2.4</em> <a class="iref" href="#rfc.xref.RFC3986.14">4.1.2</a></li> 2999 <li class="indline1"><em>Section 3.2.3</em> <a class="iref" href="#rfc.xref.RFC3986.9">2.2</a></li> 3000 <li class="indline1"><em>Section 3.2.2</em> <a class="iref" href="#rfc.xref.RFC3986.11">2.2</a></li> 3001 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.RFC3986.5">2.2</a></li> 3002 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.RFC3986.7">2.2</a>, <a class="iref" href="#rfc.xref.RFC3986.8">2.2</a></li> 3003 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.RFC3986.10">2.2</a></li> 3004 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.RFC3986.6">2.2</a></li> 3005 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.RFC3986.12">2.2</a></li> 3006 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.RFC3986.4">2.2</a></li> 3026 <li class="indline1"><em>RFC2109</em> <a class="iref" href="#rfc.xref.RFC2109.1">4.2</a>, <a class="iref" href="#RFC2109"><b>12.2</b></a></li> 3027 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>12.1</b></a>, <a class="iref" href="#rfc.xref.RFC2119.2">B.3</a></li> 3028 <li class="indline1"><em>RFC2145</em> <a class="iref" href="#rfc.xref.RFC2145.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2145.2">3.1</a>, <a class="iref" href="#RFC2145"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2145.3">B.3</a></li> 3029 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">11</a>, <a class="iref" href="#RFC2616"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">D.1</a></li> 3030 <li class="indline1"><em>RFC2818</em> <a class="iref" href="#rfc.xref.RFC2818.1">2.1.1</a>, <a class="iref" href="#RFC2818"><b>12.2</b></a></li> 3031 <li class="indline1"><em>RFC2965</em> <a class="iref" href="#rfc.xref.RFC2965.1">4.2</a>, <a class="iref" href="#RFC2965"><b>12.2</b></a></li> 3032 <li class="indline1"><em>RFC3864</em> <a class="iref" href="#rfc.xref.RFC3864.1">9.1</a>, <a class="iref" href="#RFC3864"><b>12.2</b></a></li> 3033 <li class="indline1"><em>RFC3977</em> <a class="iref" href="#rfc.xref.RFC3977.1">1</a>, <a class="iref" href="#RFC3977"><b>12.2</b></a></li> 3034 <li class="indline1"><em>RFC3986</em> <a class="iref" href="#rfc.xref.RFC3986.1">1</a>, <a class="iref" href="#rfc.xref.RFC3986.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.3">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.4">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.5">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.6">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.7">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.8">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.9">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.10">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.11">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.12">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.13">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.14">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.15">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.16">2.1.2</a>, <a class="iref" href="#rfc.xref.RFC3986.17">5.1.2</a>, <a class="iref" href="#RFC3986"><b>12.1</b></a><ul class="ind"> 3035 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.RFC3986.16">2.1.2</a></li> 3036 <li class="indline1"><em>Section 2.4</em> <a class="iref" href="#rfc.xref.RFC3986.17">5.1.2</a></li> 3037 <li class="indline1"><em>Section 3.2.3</em> <a class="iref" href="#rfc.xref.RFC3986.13">2.1</a></li> 3038 <li class="indline1"><em>Section 3.2.2</em> <a class="iref" href="#rfc.xref.RFC3986.15">2.1</a></li> 3039 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.RFC3986.9">2.1</a></li> 3040 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.RFC3986.11">2.1</a>, <a class="iref" href="#rfc.xref.RFC3986.12">2.1</a></li> 3041 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.RFC3986.14">2.1</a></li> 3042 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.RFC3986.10">2.1</a></li> 3043 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.RFC3986.5">2.1</a></li> 3044 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.RFC3986.6">2.1</a></li> 3045 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.RFC3986.8">2.1</a></li> 3046 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.RFC3986.7">2.1</a></li> 3007 3047 </ul> 3008 3048 </li> 3009 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#rfc.xref.RFC4288.1"> 8.3</a>, <a class="iref" href="#RFC4288"><b>11.2</b></a></li>3010 <li class="indline1"><em>RFC4395</em> <a class="iref" href="#rfc.xref.RFC4395.1"> 8.2</a>, <a class="iref" href="#RFC4395"><b>11.2</b></a></li>3011 <li class="indline1"><em>RFC5234</em> <a class="iref" href="#rfc.xref.RFC5234.1">1.2</a>, <a class="iref" href="#rfc.xref.RFC5234.2">1.2</a>, <a class="iref" href="#rfc.xref.RFC5234.3">1.2.1</a>, <a class="iref" href="#rfc.xref.RFC5234.4">1 0</a>, <a class="iref" href="#RFC5234"><b>11.1</b></a><ul class="ind">3049 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#rfc.xref.RFC4288.1">9.3</a>, <a class="iref" href="#RFC4288"><b>12.2</b></a></li> 3050 <li class="indline1"><em>RFC4395</em> <a class="iref" href="#rfc.xref.RFC4395.1">9.2</a>, <a class="iref" href="#RFC4395"><b>12.2</b></a></li> 3051 <li class="indline1"><em>RFC5234</em> <a class="iref" href="#rfc.xref.RFC5234.1">1.2</a>, <a class="iref" href="#rfc.xref.RFC5234.2">1.2</a>, <a class="iref" href="#rfc.xref.RFC5234.3">1.2.1</a>, <a class="iref" href="#rfc.xref.RFC5234.4">11</a>, <a class="iref" href="#RFC5234"><b>12.1</b></a><ul class="ind"> 3012 3052 <li class="indline1"><em>Appendix B.1</em> <a class="iref" href="#rfc.xref.RFC5234.2">1.2</a></li> 3013 3053 </ul> 3014 3054 </li> 3015 <li class="indline1"><em>RFC5322</em> <a class="iref" href="#rfc.xref.RFC5322.1">1</a>, <a class="iref" href="#rfc.xref.RFC5322.2"> 3.1</a>, <a class="iref" href="#rfc.xref.RFC5322.3">3.2</a>, <a class="iref" href="#rfc.xref.RFC5322.4">7.3</a>, <a class="iref" href="#rfc.xref.RFC5322.5">7.9</a>, <a class="iref" href="#RFC5322"><b>11.2</b></a><ul class="ind">3016 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.RFC5322.3"> 3.2</a></li>3017 <li class="indline1"><em>Section 3.6.1</em> <a class="iref" href="#rfc.xref.RFC5322.4"> 7.3</a></li>3018 <li class="indline1"><em>Section 3.6.7</em> <a class="iref" href="#rfc.xref.RFC5322.5"> 7.9</a></li>3055 <li class="indline1"><em>RFC5322</em> <a class="iref" href="#rfc.xref.RFC5322.1">1</a>, <a class="iref" href="#rfc.xref.RFC5322.2">4.1</a>, <a class="iref" href="#rfc.xref.RFC5322.3">4.2</a>, <a class="iref" href="#rfc.xref.RFC5322.4">8.3</a>, <a class="iref" href="#rfc.xref.RFC5322.5">8.9</a>, <a class="iref" href="#RFC5322"><b>12.2</b></a><ul class="ind"> 3056 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.RFC5322.3">4.2</a></li> 3057 <li class="indline1"><em>Section 3.6.1</em> <a class="iref" href="#rfc.xref.RFC5322.4">8.3</a></li> 3058 <li class="indline1"><em>Section 3.6.7</em> <a class="iref" href="#rfc.xref.RFC5322.5">8.9</a></li> 3019 3059 </ul> 3020 3060 </li> 3021 <li class="indline1"><em>RFC959</em> <a class="iref" href="#rfc.xref.RFC959.1">1</a>, <a class="iref" href="#RFC959"><b>1 1.2</b></a></li>3061 <li class="indline1"><em>RFC959</em> <a class="iref" href="#rfc.xref.RFC959.1">1</a>, <a class="iref" href="#RFC959"><b>12.2</b></a></li> 3022 3062 </ul> 3023 3063 </li> 3024 3064 <li class="indline0"><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul class="ind"> 3025 3065 <li class="indline1">server <a class="iref" href="#rfc.iref.s.1">C</a></li> 3026 <li class="indline1"><em>Spe</em> <a class="iref" href="#rfc.xref.Spe.1"> 6.1.1</a>, <a class="iref" href="#Spe"><b>11.2</b></a></li>3066 <li class="indline1"><em>Spe</em> <a class="iref" href="#rfc.xref.Spe.1">7.1.1</a>, <a class="iref" href="#Spe"><b>12.2</b></a></li> 3027 3067 </ul> 3028 3068 </li> 3029 3069 <li class="indline0"><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul class="ind"> 3030 <li class="indline1">TE header <a class="iref" href="#rfc.xref.header.te.1"> 2.4</a>, <a class="iref" href="#rfc.xref.header.te.2">2.4.1</a>, <a class="iref" href="#rfc.iref.t.1"><b>7.5</b></a>, <a class="iref" href="#rfc.xref.header.te.3">8.1</a>, <a class="iref" href="#rfc.xref.header.te.4">B.3</a></li>3031 <li class="indline1"><em>Tou1998</em> <a class="iref" href="#rfc.xref.Tou1998.1"> 6.1.1</a>, <a class="iref" href="#Tou1998"><b>11.2</b></a></li>3032 <li class="indline1">Trailer header <a class="iref" href="#rfc.xref.header.trailer.1"> 2.4.1</a>, <a class="iref" href="#rfc.xref.header.trailer.2">3.5</a>, <a class="iref" href="#rfc.iref.t.2"><b>7.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">8.1</a></li>3033 <li class="indline1">Transfer-Encoding header <a class="iref" href="#rfc.xref.header.transfer-encoding.1"> 2.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">3.5</a>, <a class="iref" href="#rfc.iref.t.3"><b>7.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">8.1</a></li>3070 <li class="indline1">TE header <a class="iref" href="#rfc.xref.header.te.1">3.3</a>, <a class="iref" href="#rfc.xref.header.te.2">3.3.1</a>, <a class="iref" href="#rfc.iref.t.1"><b>8.5</b></a>, <a class="iref" href="#rfc.xref.header.te.3">9.1</a>, <a class="iref" href="#rfc.xref.header.te.4">B.3</a></li> 3071 <li class="indline1"><em>Tou1998</em> <a class="iref" href="#rfc.xref.Tou1998.1">7.1.1</a>, <a class="iref" href="#Tou1998"><b>12.2</b></a></li> 3072 <li class="indline1">Trailer header <a class="iref" href="#rfc.xref.header.trailer.1">3.3.1</a>, <a class="iref" href="#rfc.xref.header.trailer.2">4.5</a>, <a class="iref" href="#rfc.iref.t.2"><b>8.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">9.1</a></li> 3073 <li class="indline1">Transfer-Encoding header <a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">4.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">4.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">4.5</a>, <a class="iref" href="#rfc.iref.t.3"><b>8.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">9.1</a></li> 3034 3074 <li class="indline1">tunnel <a class="iref" href="#rfc.iref.t.4">C</a></li> 3035 3075 </ul> 3036 3076 </li> 3037 3077 <li class="indline0"><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul class="ind"> 3038 <li class="indline1">Upgrade header <a class="iref" href="#rfc.xref.header.upgrade.1"> 3.5</a>, <a class="iref" href="#rfc.iref.u.3"><b>7.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">8.1</a></li>3078 <li class="indline1">Upgrade header <a class="iref" href="#rfc.xref.header.upgrade.1">4.5</a>, <a class="iref" href="#rfc.iref.u.3"><b>8.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">9.1</a></li> 3039 3079 <li class="indline1">upstream <a class="iref" href="#rfc.iref.u.5">C</a></li> 3040 3080 <li class="indline1">URI scheme 3041 3081 <ul class="ind"> 3042 <li class="indline1">http <a class="iref" href="#rfc.iref.u.1"><b>2. 2.1</b></a></li>3043 <li class="indline1">https <a class="iref" href="#rfc.iref.u.2">2. 2.1</a></li>3082 <li class="indline1">http <a class="iref" href="#rfc.iref.u.1"><b>2.1.1</b></a></li> 3083 <li class="indline1">https <a class="iref" href="#rfc.iref.u.2">2.1.1</a></li> 3044 3084 </ul> 3045 3085 </li> 3046 <li class="indline1"><em>USASCII</em> <a class="iref" href="#rfc.xref.USASCII.1">1.2</a>, <a class="iref" href="#USASCII"><b>1 1.1</b></a></li>3086 <li class="indline1"><em>USASCII</em> <a class="iref" href="#rfc.xref.USASCII.1">1.2</a>, <a class="iref" href="#USASCII"><b>12.1</b></a></li> 3047 3087 <li class="indline1">user agent <a class="iref" href="#rfc.iref.u.4">C</a></li> 3048 3088 </ul> … … 3050 3090 <li class="indline0"><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul class="ind"> 3051 3091 <li class="indline1">variant <a class="iref" href="#rfc.iref.v.2">C</a></li> 3052 <li class="indline1">Via header <a class="iref" href="#rfc.xref.header.via.1"> 3.5</a>, <a class="iref" href="#rfc.iref.v.1"><b>7.9</b></a>, <a class="iref" href="#rfc.xref.header.via.2">8.1</a></li>3092 <li class="indline1">Via header <a class="iref" href="#rfc.xref.header.via.1">4.5</a>, <a class="iref" href="#rfc.iref.v.1"><b>8.9</b></a>, <a class="iref" href="#rfc.xref.header.via.2">9.1</a></li> 3053 3093 </ul> 3054 3094 </li> 3055 3095 <li class="indline0"><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul class="ind"> 3056 <li class="indline1"><em>WAIS</em> <a class="iref" href="#rfc.xref.WAIS.1">1</a>, <a class="iref" href="#WAIS"><b>1 1.2</b></a></li>3096 <li class="indline1"><em>WAIS</em> <a class="iref" href="#rfc.xref.WAIS.1">1</a>, <a class="iref" href="#WAIS"><b>12.2</b></a></li> 3057 3097 </ul> 3058 3098 </li> -
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 -
draft-ietf-httpbis/latest/p2-semantics.html
r386 r391 477 477 <tr> 478 478 <td class="header left"></td> 479 <td class="header right">November 1 4, 2008</td>479 <td class="header right">November 15, 2008</td> 480 480 </tr> 481 481 </table> … … 588 588 <li class="tocline1">9.4.13 <a href="#status.412">412 Precondition Failed</a></li> 589 589 <li class="tocline1">9.4.14 <a href="#status.413">413 Request Entity Too Large</a></li> 590 <li class="tocline1">9.4.15 <a href="#status.414">414 Request- URIToo Long</a></li>590 <li class="tocline1">9.4.15 <a href="#status.414">414 Request-target Too Long</a></li> 591 591 <li class="tocline1">9.4.16 <a href="#status.415">415 Unsupported Media Type</a></li> 592 592 <li class="tocline1">9.4.17 <a href="#status.416">416 Requested Range Not Satisfiable</a></li> … … 673 673 </p> 674 674 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="notation" href="#notation">Notational Conventions and Generic Grammar</a></h1> 675 <p id="rfc.section.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 2.1</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and the core rules defined in <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section2.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:676 </p> 677 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#notation" class="smpl">CR</a> = <CR, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>>678 <a href="#notation" class="smpl">DIGIT</a> = <DIGIT, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>>679 <a href="#notation" class="smpl">LF</a> = <LF, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>>680 </pre><div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#notation" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>>681 <a href="#notation" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>>682 <a href="#notation" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>>683 <a href="#notation" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>>684 <a href="#notation" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>>685 <a href="#notation" class="smpl">TEXT</a> = <TEXT, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>>675 <p id="rfc.section.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and the core rules defined in <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: 676 </p> 677 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#notation" class="smpl">CR</a> = <CR, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 678 <a href="#notation" class="smpl">DIGIT</a> = <DIGIT, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 679 <a href="#notation" class="smpl">LF</a> = <LF, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 680 </pre><div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#notation" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 681 <a href="#notation" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 682 <a href="#notation" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 683 <a href="#notation" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 684 <a href="#notation" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 685 <a href="#notation" class="smpl">TEXT</a> = <TEXT, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 686 686 </pre><div id="abnf.dependencies"> 687 687 <p id="rfc.section.2.p.4"> The ABNF rules below are defined in other parts:</p> 688 688 </div> 689 <div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 3.2</a>>690 <a href="#abnf.dependencies" class="smpl">fragment</a> = <fragment, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 3.2</a>>691 <a href="#abnf.dependencies" class="smpl">Host</a> = <Host, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 3.2</a>>692 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#full.date" title="Full Date">Section 3. 3.1</a>>693 <a href="#abnf.dependencies" class="smpl">p roduct</a> = <product, defined in <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.5</a>>694 <a href="#abnf.dependencies" class="smpl"> relativeURI</a> = <relativeURI, defined in <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 3.2</a>>689 <div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>> 690 <a href="#abnf.dependencies" class="smpl">fragment</a> = <fragment, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>> 691 <a href="#abnf.dependencies" class="smpl">Host</a> = <Host, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>> 692 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#full.date" title="Full Date">Section 3.2.1</a>> 693 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>> 694 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.4</a>> 695 695 <a href="#abnf.dependencies" class="smpl">TE</a> = <TE, defined in <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.8</a>> 696 696 </pre><div id="rfc.figure.u.4"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Accept</a> = <Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>> … … 721 721 <WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a>> 722 722 </pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="method" href="#method">Method</a></h1> 723 <p id="rfc.section.3.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p>723 <p id="rfc.section.3.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. The method is case-sensitive.</p> 724 724 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> <a href="#method" class="smpl">Method</a> = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 8.2</a> 725 725 / %x47.45.54 ; "GET", <a href="#GET" id="rfc.xref.GET.1" title="GET">Section 8.3</a> … … 820 820 / "412" ; <a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section 9.4.13</a>: Precondition Failed 821 821 / "413" ; <a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Entity Too Large">Section 9.4.14</a>: Request Entity Too Large 822 / "414" ; <a href="#status.414" id="rfc.xref.status.414.1" title="414 Request- URI Too Long">Section 9.4.15</a>: Request-URIToo Large822 / "414" ; <a href="#status.414" id="rfc.xref.status.414.1" title="414 Request-target Too Long">Section 9.4.15</a>: Request-target Too Large 823 823 / "415" ; <a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section 9.4.16</a>: Unsupported Media Type 824 824 / "416" ; <a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section 9.4.17</a>: Requested range not satisfiable … … 850 850 <p id="rfc.section.6.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the 851 851 Status-Line. These header fields give information about the server and about further access to the resource identified by 852 the Request-URI.852 the request-target. 853 853 </p> 854 854 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a> ; <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 6.1</a> … … 910 910 <div id="rfc.iref.m.1"></div> 911 911 <p id="rfc.section.8.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response 912 chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated912 chain identified by the request-target. This method allows the client to determine the options and/or requirements associated 913 913 with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 914 914 </p> … … 918 918 to HTTP might use the OPTIONS body to make more detailed queries on the server. 919 919 </p> 920 <p id="rfc.section.8.2.p.4">If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to921 a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful920 <p id="rfc.section.8.2.p.4">If the request-target is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than 921 to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful 922 922 as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. 923 923 For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof). 924 924 </p> 925 <p id="rfc.section.8.2.p.5">If the Request-URIis not an asterisk, the OPTIONS request applies only to the options that are available when communicating925 <p id="rfc.section.8.2.p.5">If the request-target is not an asterisk, the OPTIONS request applies only to the options that are available when communicating 926 926 with that resource. 927 927 </p> … … 937 937 <div id="rfc.iref.g.8"></div> 938 938 <div id="rfc.iref.m.2"></div> 939 <p id="rfc.section.8.3.p.1">The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI940 re fers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not941 the source text of the process, unless that text happens to be the output of the process.939 <p id="rfc.section.8.3.p.1">The GET method means retrieve whatever information (in the form of an entity) is identified by the request-target. If the 940 request-target refers to a data-producing process, it is the produced data which shall be returned as the entity in the response 941 and not the source text of the process, unless that text happens to be the output of the process. 942 942 </p> 943 943 <p id="rfc.section.8.3.p.2">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, … … 970 970 <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="POST" href="#POST">POST</a></h2> 971 971 <p id="rfc.section.8.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed 972 by the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the973 following functions:972 by the resource identified by the request-target in the Request-Line. POST is designed to allow a uniform method to cover 973 the following functions: 974 974 </p> 975 975 <ul> … … 979 979 <li>Extending a database through an append operation.</li> 980 980 </ul> 981 <p id="rfc.section.8.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.</p>981 <p id="rfc.section.8.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the request-target.</p> 982 982 <p id="rfc.section.8.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 983 983 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity … … 993 993 <div id="rfc.iref.m.5"></div> 994 994 <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a> <a id="PUT" href="#PUT">PUT</a></h2> 995 <p id="rfc.section.8.6.p.1">The PUT method requests that the enclosed entity be stored at the supplied Request-URI. If the Request-URI refers to an already996 existing resource, the enclosed entity <em class="bcp14">SHOULD</em> be considered as a modified version of the one residing on the origin server. If the Request-URIdoes not point to an existing995 <p id="rfc.section.8.6.p.1">The PUT method requests that the enclosed entity be stored at the supplied request-target. If the request-target refers to 996 an already existing resource, the enclosed entity <em class="bcp14">SHOULD</em> be considered as a modified version of the one residing on the origin server. If the request-target does not point to an existing 997 997 resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create 998 the resource with that URI. If a new resource is created at the Request-URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No999 Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI,998 the resource with that URI. If a new resource is created at the request-target, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No 999 Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. If the resource could not be created or modified with the request-target, 1000 1000 an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the entity <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix 'Content-') that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases. 1001 1001 </p> 1002 <p id="rfc.section.8.6.p.2">If the request passes through a cache and the Request-URIidentifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.1003 </p> 1004 <p id="rfc.section.8.6.p.3">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The1005 URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting1002 <p id="rfc.section.8.6.p.2">If the request passes through a cache and the request-target identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 1003 </p> 1004 <p id="rfc.section.8.6.p.3">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the request-target. 1005 The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting 1006 1006 process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request 1007 1007 identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server <em class="bcp14">MUST NOT</em> attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, … … 1018 1018 <div id="rfc.iref.m.6"></div> 1019 1019 <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a> <a id="DELETE" href="#DELETE">DELETE</a></h2> 1020 <p id="rfc.section.8.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation1020 <p id="rfc.section.8.7.p.1">The DELETE method requests that the origin server delete the resource identified by the request-target. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation 1021 1021 has been carried out, even if the status code returned from the origin server indicates that the action has been completed 1022 1022 successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible … … 1026 1026 or 204 (No Content) if the action has been enacted but the response does not include an entity. 1027 1027 </p> 1028 <p id="rfc.section.8.7.p.3">If the request passes through a cache and the Request-URIidentifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.1028 <p id="rfc.section.8.7.p.3">If the request passes through a cache and the request-target identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 1029 1029 </p> 1030 1030 <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2> … … 1181 1181 <div id="rfc.iref.s.12"></div> 1182 1182 <h3 id="rfc.section.9.3.2"><a href="#rfc.section.9.3.2">9.3.2</a> <a id="status.301" href="#status.301">301 Moved Permanently</a></h3> 1183 <p id="rfc.section.9.3.2.p.1">The requested resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI1183 <p id="rfc.section.9.3.2.p.1">The requested resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the request-target 1184 1184 to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise. 1185 1185 </p> … … 1198 1198 <h3 id="rfc.section.9.3.3"><a href="#rfc.section.9.3.3">9.3.3</a> <a id="status.302" href="#status.302">302 Found</a></h3> 1199 1199 <p id="rfc.section.9.3.3.p.1">The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the 1200 client <em class="bcp14">SHOULD</em> continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires1201 header field.1200 client <em class="bcp14">SHOULD</em> continue to use the request-target for future requests. This response is only cacheable if indicated by a Cache-Control or 1201 Expires header field. 1202 1202 </p> 1203 1203 <p id="rfc.section.9.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). … … 1252 1252 <div id="rfc.iref.s.18"></div> 1253 1253 <h3 id="rfc.section.9.3.8"><a href="#rfc.section.9.3.8">9.3.8</a> <a id="status.307" href="#status.307">307 Temporary Redirect</a></h3> 1254 <p id="rfc.section.9.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection <em class="bcp14">MAY</em> be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires1255 header field.1254 <p id="rfc.section.9.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection <em class="bcp14">MAY</em> be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the request-target for future requests. This response is only cacheable if indicated by a Cache-Control or 1255 Expires header field. 1256 1256 </p> 1257 1257 <p id="rfc.section.9.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand … … 1295 1295 <div id="rfc.iref.s.23"></div> 1296 1296 <h3 id="rfc.section.9.4.5"><a href="#rfc.section.9.4.5">9.4.5</a> <a id="status.404" href="#status.404">404 Not Found</a></h3> 1297 <p id="rfc.section.9.4.5.p.1">The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or1298 permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable1297 <p id="rfc.section.9.4.5.p.1">The server has not found anything matching the request-target. No indication is given of whether the condition is temporary 1298 or permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable 1299 1299 and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request 1300 1300 has been refused, or when no other response is applicable. … … 1303 1303 <div id="rfc.iref.s.24"></div> 1304 1304 <h3 id="rfc.section.9.4.6"><a href="#rfc.section.9.4.6">9.4.6</a> <a id="status.405" href="#status.405">405 Method Not Allowed</a></h3> 1305 <p id="rfc.section.9.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource.1305 <p id="rfc.section.9.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the request-target. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource. 1306 1306 </p> 1307 1307 <div id="rfc.iref.48"></div> … … 1350 1350 <h3 id="rfc.section.9.4.11"><a href="#rfc.section.9.4.11">9.4.11</a> <a id="status.410" href="#status.410">410 Gone</a></h3> 1351 1351 <p id="rfc.section.9.4.11.p.1">The requested resource is no longer available at the server and no forwarding address is known. This condition is expected 1352 to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether1353 or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead. This response is cacheable unless indicated otherwise.1352 to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the request-target after user approval. If the server does not know, or has no facility to determine, 1353 whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead. This response is cacheable unless indicated otherwise. 1354 1354 </p> 1355 1355 <p id="rfc.section.9.4.11.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource … … 1381 1381 <div id="rfc.iref.56"></div> 1382 1382 <div id="rfc.iref.s.33"></div> 1383 <h3 id="rfc.section.9.4.15"><a href="#rfc.section.9.4.15">9.4.15</a> <a id="status.414" href="#status.414">414 Request- URIToo Long</a></h3>1384 <p id="rfc.section.9.4.15.p.1">The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This1385 rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query1386 information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points1387 to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some1388 servers using fixed-length buffers for reading or manipulating the Request-URI.1383 <h3 id="rfc.section.9.4.15"><a href="#rfc.section.9.4.15">9.4.15</a> <a id="status.414" href="#status.414">414 Request-target Too Long</a></h3> 1384 <p id="rfc.section.9.4.15.p.1">The server is refusing to service the request because the request-target is longer than the server is willing to interpret. 1385 This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long 1386 query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that 1387 points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present 1388 in some servers using fixed-length buffers for reading or manipulating the request-target. 1389 1389 </p> 1390 1390 <div id="rfc.iref.57"></div> … … 1462 1462 <div id="rfc.iref.h.2"></div> 1463 1463 <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2> 1464 <p id="rfc.section.10.1.p.1">The response-header field "Allow" lists the set of methods advertised as supported by the resource identified by the Request-URI.1464 <p id="rfc.section.10.1.p.1">The response-header field "Allow" lists the set of methods advertised as supported by the resource identified by the request-target. 1465 1465 The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header 1466 1466 field <em class="bcp14">MUST</em> be present in a 405 (Method Not Allowed) response. … … 1526 1526 <h2 id="rfc.section.10.4"><a href="#rfc.section.10.4">10.4</a> <a id="header.location" href="#header.location">Location</a></h2> 1527 1527 <p id="rfc.section.10.4.p.1">The response-header field "Location" is used for the identification of a new resource or to redirect the recipient to a location 1528 other than the Request-URI for completion of the request. For 201 (Created) responses, the Location is that of the new resource1529 which was created by the request. For 3xx responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute1528 other than the request-target for completion of the request. For 201 (Created) responses, the Location is that of the new 1529 resource which was created by the request. For 3xx responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute 1530 1530 URI. 1531 1531 </p> … … 1566 1566 <h2 id="rfc.section.10.6"><a href="#rfc.section.10.6">10.6</a> <a id="header.referer" href="#header.referer">Referer</a></h2> 1567 1567 <p id="rfc.section.10.6.p.1">The request-header field "Referer" [sic] allows the client to specify, for the server's benefit, the address (URI) of the 1568 resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header1569 allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows1570 obsolete or mistyped links to be traced for maintenance. The Referer field <em class="bcp14">MUST NOT</em> be sent if the Request-URIwas obtained from a source that does not have its own URI, such as input from the user keyboard.1568 resource from which the request-target was obtained (the "referrer", although the header field is misspelled.) The Referer 1569 request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. 1570 It also allows obsolete or mistyped links to be traced for maintenance. The Referer field <em class="bcp14">MUST NOT</em> be sent if the request-target was obtained from a source that does not have its own URI, such as input from the user keyboard. 1571 1571 </p> 1572 1572 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> <a href="#header.referer" class="smpl">Referer</a> = "Referer" ":" <a href="#notation" class="smpl">OWS</a> <a href="#header.referer" class="smpl">Referer-v</a> 1573 <a href="#header.referer" class="smpl">Referer-v</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl"> relativeURI</a>1573 <a href="#header.referer" class="smpl">Referer-v</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 1574 1574 </pre><p id="rfc.section.10.6.p.3">Example:</p> 1575 1575 <div id="rfc.figure.u.22"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 1576 </pre><p id="rfc.section.10.6.p.5">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the Request-URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 12.2</a> for security considerations.1576 </pre><p id="rfc.section.10.6.p.5">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the request-target. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 12.2</a> for security considerations. 1577 1577 </p> 1578 1578 <div id="rfc.iref.r.2"></div> … … 1598 1598 <h2 id="rfc.section.10.8"><a href="#rfc.section.10.8">10.8</a> <a id="header.server" href="#header.server">Server</a></h2> 1599 1599 <p id="rfc.section.10.8.p.1">The response-header field "Server" contains information about the software used by the origin server to handle the request. 1600 The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3. 5</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance1600 The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.4</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance 1601 1601 for identifying the application. 1602 1602 </p> … … 1619 1619 <p id="rfc.section.10.9.p.1">The request-header field "User-Agent" contains information about the user agent originating the request. This is for statistical 1620 1620 purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses 1621 to avoid particular user agent limitations. User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3. 5</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the1621 to avoid particular user agent limitations. User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.4</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the 1622 1622 product tokens are listed in order of their significance for identifying the application. 1623 1623 </p> … … 1899 1899 <tr> 1900 1900 <td>414</td> 1901 <td>Request- URIToo Long</td>1902 <td> <a href="#status.414" id="rfc.xref.status.414.2" title="414 Request- URIToo Long">Section 9.4.15</a>1901 <td>Request-target Too Long</td> 1902 <td> <a href="#status.414" id="rfc.xref.status.414.2" title="414 Request-target Too Long">Section 9.4.15</a> 1903 1903 </td> 1904 1904 </tr> … … 2082 2082 </p> 2083 2083 <p id="rfc.section.12.2.p.3">Authors of services should not use GET-based forms for the submission of sensitive data because that data will be encoded 2084 in the Request- URI. Many existing servers, proxies, and user agents log or display the Request-URI in places where it might2085 be visible to third parties. Such services can use POST-based form submission instead.2084 in the Request-target. Many existing servers, proxies, and user agents log or display the Request-target in places where it 2085 might be visible to third parties. Such services can use POST-based form submission instead. 2086 2086 </p> 2087 2087 <h2 id="rfc.section.12.3"><a href="#rfc.section.12.3">12.3</a> <a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2> … … 2411 2411 <li class="indline1">412 Precondition Failed (status code) <a class="iref" href="#rfc.xref.status.412.1">5</a>, <a class="iref" href="#rfc.iref.54"><b>9.4.13</b></a>, <a class="iref" href="#rfc.xref.status.412.2">11.2</a></li> 2412 2412 <li class="indline1">413 Request Entity Too Large (status code) <a class="iref" href="#rfc.xref.status.413.1">5</a>, <a class="iref" href="#rfc.iref.55"><b>9.4.14</b></a>, <a class="iref" href="#rfc.xref.status.413.2">11.2</a></li> 2413 <li class="indline1">414 Request- URIToo Long (status code) <a class="iref" href="#rfc.xref.status.414.1">5</a>, <a class="iref" href="#rfc.iref.56"><b>9.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">11.2</a></li>2413 <li class="indline1">414 Request-target Too Long (status code) <a class="iref" href="#rfc.xref.status.414.1">5</a>, <a class="iref" href="#rfc.iref.56"><b>9.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">11.2</a></li> 2414 2414 <li class="indline1">415 Unsupported Media Type (status code) <a class="iref" href="#rfc.xref.status.415.1">5</a>, <a class="iref" href="#rfc.iref.57"><b>9.4.16</b></a>, <a class="iref" href="#rfc.xref.status.415.2">11.2</a></li> 2415 2415 <li class="indline1">416 Requested Range Not Satisfiable (status code) <a class="iref" href="#rfc.xref.status.416.1">5</a>, <a class="iref" href="#rfc.iref.58"><b>9.4.17</b></a>, <a class="iref" href="#rfc.xref.status.416.2">11.2</a></li> … … 2534 2534 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2535 2535 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.11">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a>, <a class="iref" href="#rfc.xref.Part1.13">2</a>, <a class="iref" href="#rfc.xref.Part1.14">2</a>, <a class="iref" href="#rfc.xref.Part1.15">2</a>, <a class="iref" href="#rfc.xref.Part1.16">2</a>, <a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.18">2</a>, <a class="iref" href="#rfc.xref.Part1.19">2</a>, <a class="iref" href="#rfc.xref.Part1.20">4</a>, <a class="iref" href="#rfc.xref.Part1.21">4</a>, <a class="iref" href="#rfc.xref.Part1.22">7</a>, <a class="iref" href="#rfc.xref.Part1.23">8.8</a>, <a class="iref" href="#rfc.xref.Part1.24">8.8</a>, <a class="iref" href="#rfc.xref.Part1.25">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.26">9.5.6</a>, <a class="iref" href="#rfc.xref.Part1.27">10.2</a>, <a class="iref" href="#rfc.xref.Part1.28">10.8</a>, <a class="iref" href="#rfc.xref.Part1.29">10.8</a>, <a class="iref" href="#rfc.xref.Part1.30">10.9</a>, <a class="iref" href="#Part1"><b>14.1</b></a>, <a class="iref" href="#rfc.xref.Part1.31">A.2</a><ul class="ind"> 2536 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.Part1.2">2</a></li> 2537 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.11">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a></li> 2536 <li class="indline1"><em>Section 1.2.1</em> <a class="iref" href="#rfc.xref.Part1.2">2</a></li> 2537 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.11">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a></li> 2538 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.Part1.13">2</a>, <a class="iref" href="#rfc.xref.Part1.14">2</a>, <a class="iref" href="#rfc.xref.Part1.15">2</a>, <a class="iref" href="#rfc.xref.Part1.17">2</a></li> 2538 2539 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part1.26">9.5.6</a></li> 2539 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.13">2</a>, <a class="iref" href="#rfc.xref.Part1.14">2</a>, <a class="iref" href="#rfc.xref.Part1.15">2</a>, <a class="iref" href="#rfc.xref.Part1.18">2</a></li> 2540 <li class="indline1"><em>Section 3.3.1</em> <a class="iref" href="#rfc.xref.Part1.16">2</a></li> 2541 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.28">10.8</a>, <a class="iref" href="#rfc.xref.Part1.30">10.9</a></li> 2540 <li class="indline1"><em>Section 3.2.1</em> <a class="iref" href="#rfc.xref.Part1.16">2</a></li> 2541 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part1.18">2</a>, <a class="iref" href="#rfc.xref.Part1.28">10.8</a>, <a class="iref" href="#rfc.xref.Part1.30">10.9</a></li> 2542 2542 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.22">7</a></li> 2543 2543 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.25">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.27">10.2</a></li> … … 2649 2649 <li class="indline1">412 Precondition Failed <a class="iref" href="#rfc.xref.status.412.1">5</a>, <a class="iref" href="#rfc.iref.s.31"><b>9.4.13</b></a>, <a class="iref" href="#rfc.xref.status.412.2">11.2</a></li> 2650 2650 <li class="indline1">413 Request Entity Too Large <a class="iref" href="#rfc.xref.status.413.1">5</a>, <a class="iref" href="#rfc.iref.s.32"><b>9.4.14</b></a>, <a class="iref" href="#rfc.xref.status.413.2">11.2</a></li> 2651 <li class="indline1">414 Request- URIToo Long <a class="iref" href="#rfc.xref.status.414.1">5</a>, <a class="iref" href="#rfc.iref.s.33"><b>9.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">11.2</a></li>2651 <li class="indline1">414 Request-target Too Long <a class="iref" href="#rfc.xref.status.414.1">5</a>, <a class="iref" href="#rfc.iref.s.33"><b>9.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">11.2</a></li> 2652 2652 <li class="indline1">415 Unsupported Media Type <a class="iref" href="#rfc.xref.status.415.1">5</a>, <a class="iref" href="#rfc.iref.s.34"><b>9.4.16</b></a>, <a class="iref" href="#rfc.xref.status.415.2">11.2</a></li> 2653 2653 <li class="indline1">416 Requested Range Not Satisfiable <a class="iref" href="#rfc.xref