DOCSLIB.ORG

Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing Internet Engineering Task Force (IETF) R. Fielding, Editor Request for Comments: 7230 Adobe Obsoletes: 2145, 2616 J. Reschke, Editor Updates: 2817, 2818 greenbytes Category: Standards Track June 2014 ISSN: 2070-1721 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing Abstract The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 57411. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc72302. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info3) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be 1 https://www.rfc-editor.org/rfc/rfc5741.html#section-2 2 http://www.rfc-editor.org/info/rfc7230 3 http://trustee.ietf.org/license-info RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Fielding & Reschke Standards Track [Page 2] RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014 Table of Contents 1 Introduction...............................................................................................................................................................6 1.1 Requirements Notation.......................................................................................................................................... 6 1.2 Syntax Notation..................................................................................................................................................... 6 2 Architecture...............................................................................................................................................................8 2.1 Client/Server Messaging........................................................................................................................................8 2.2 Implementation Diversity...................................................................................................................................... 9 2.3 Intermediaries.........................................................................................................................................................9 2.4 Caches.................................................................................................................................................................. 10 2.5 Conformance and Error Handling.......................................................................................................................11 2.6 Protocol Versioning.............................................................................................................................................12 2.7 Uniform Resource Identifiers..............................................................................................................................13 2.7.1 http URI Scheme............................................................................................................................................ 14 2.7.2 https URI Scheme...........................................................................................................................................15 2.7.3 http and https URI Normalization and Comparison...................................................................................... 15 3 Message Format......................................................................................................................................................16 3.1 Start Line............................................................................................................................................................. 16 3.1.1 Request Line................................................................................................................................................... 16 3.1.2 Status Line...................................................................................................................................................... 17 3.2 Header Fields.......................................................................................................................................................17 3.2.1 Field Extensibility...........................................................................................................................................18 3.2.2 Field Order......................................................................................................................................................18 3.2.3 Whitespace...................................................................................................................................................... 18 3.2.4 Field Parsing................................................................................................................................................... 19 3.2.5 Field Limits.....................................................................................................................................................20 3.2.6 Field Value Components................................................................................................................................ 20 3.3 Message Body......................................................................................................................................................21 3.3.1 Transfer-Encoding.......................................................................................................................................... 21 3.3.2 Content-Length............................................................................................................................................... 22 3.3.3 Message Body Length....................................................................................................................................23 3.4 Handling Incomplete Messages...........................................................................................................................24 3.5 Message Parsing Robustness...............................................................................................................................24 4 Transfer Codings.................................................................................................................................................... 26 4.1 Chunked Transfer Coding................................................................................................................................... 26 4.1.1 Chunk Extensions........................................................................................................................................... 26 4.1.2 Chunked Trailer Part...................................................................................................................................... 27 4.1.3 Decoding Chunked......................................................................................................................................... 27 4.2 Compression Codings..........................................................................................................................................28 4.2.1 Compress Coding............................................................................................................................................28 4.2.2 Deflate Coding................................................................................................................................................28 4.2.3 Gzip Coding....................................................................................................................................................28 4.3 TE.........................................................................................................................................................................28
Load more

Recommended publications
  • 2765 Sun Microsystems Category: Standards Track February 2000
    Network Working Group E. Nordmark Request for Comments: 2765 Sun Microsystems Category: Standards Track February 2000 Stateless IP/ICMP Translation Algorithm (SIIT) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in [TRANS-MECH]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes". This new algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts. The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts. Acknowledgements This document is a product of the NGTRANS working group. Some text has been extracted from an old Internet Draft titled "IPAE: The SIPP Interoperability and Transition Mechanism" authored by R. Gilligan, E. Nordmark, and B. Hinden. George Tsirtsis provides the figures for Section 1. Keith Moore provided a careful review of the document. Nordmark Standards Track [Page 1] RFC 2765 SIIT February 2000 Table of Contents 1. Introduction and Motivation.............................. 2 1.1. Applicability and Limitations......................
    [Show full text]
  • 3068 Microsoft Category: Standards Track June 2001 an Anycast
    Network Working Group C. Huitema Request for Comments: 3068 Microsoft Category: Standards Track June 2001 An Anycast Prefix for 6to4 Relay Routers Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the "6to4 relay anycast prefix." 1 Introduction According to [RFC3056], there are two deployment options for a 6to4 routing domain, depending on whether or not the domain is using an IPv6 exterior routing protocol. If a routing protocol is used, then the 6to4 routers acquire routes to all existing IPv6 networks through the combination of EGP and IGP. If no IPv6 exterior routing protocol is used, the 6to4 routers using a given relay router each have a default IPv6 route pointing to the relay router. This second case is typically used by small networks; for these networks, finding and configuring the default route is in practice a significant hurdle. In addition, even when the managers of these networks find an available route, this route often points to a router on the other side of the Internet, leading to very poor performance.
    [Show full text]
  • IPJ-V3N1-Rev11.Fm
    March 2000 Volume 3, Number 1 A Quarterly Technical Publication for From The Editor Internet and Intranet Professionals In This Issue Work on a new version of the Internet Protocol, known as IPv6, has been under way for several years in the IETF. There is still some debate From the Editor .......................1 about when and how IPv6 will be deployed. Proponents of IPv6 argue that the demand for new IP addresses will continue to rise to a point where we will simply run out of available IPv4 addresses and that we Routing IPv6 over IPv4............2 should, therefore, start deploying IPv6 today. Opponents argue that such a protocol transition will be too costly and painful for most organiza- IP Security..............................11 tions. They also argue that careful address management and the use of Network Address Translation (NAT) will allow continued use of the IPv4 address space for a very long time. Regardless of the timeframe, a QoS—Fact or Fiction? ...........27 major factor in the deployment of IPv6 is an appropriate transition strat- egy that allows existing IPv4 systems to communicate with new IPv6 Book Review..........................35 systems. A transition mechanism, known as “6to4,” is described in our first article by Brian Carpenter, Keith Moore, and Bob Fink. Call for Papers .......................38 In previous editions of this journal, we have looked at various security technologies for use in the Internet. Security mechanisms have been added at every layer of the protocol stack, and IP itself is no exception. Fragments ..............................39 IP Security, commonly known as “IPSec,” is being deployed in many public and private networks.
    [Show full text]
  • EXPEDIA, INC.; HOMEAWAY.COM, INC.; HOTELS.COM L.P.; HOTWIRE, INC.; and ORBITZ, LLC Petitioners
    UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ EXPEDIA, INC.; HOMEAWAY.COM, INC.; HOTELS.COM L.P.; HOTWIRE, INC.; AND ORBITZ, LLC Petitioners v. INTERNATIONAL BUSINESS MACHINES CORP. Patent Owner ____________ Case No. Unassigned Patent 6,374,359 ____________ PETITION FOR INTER PARTES REVIEW OF CLAIMS 1-16 OF U.S. PATENT NO. 6,374,359 Petition for IPR of U.S. Patent 6,374,359 TABLE OF CONTENTS I. INTRODUCTION ......................................................................................... 1 Summary of Unpatentability Grounds .................................................. 1 II. MANDATORY NOTICES, STANDING, AND FEES .............................. 1 Mandatory Notices ................................................................................ 1 Certification of Grounds for Standing ................................................... 3 Fees ........................................................................................................ 3 III. OVERVIEW OF THE ’359 Patent .............................................................. 3 Subject Matter of the ’359 Patent .......................................................... 3 Claims of the ’359 Patent ...................................................................... 5 Prosecution History of the ’359 Patent ................................................. 6 Ordinary Skill in the Art ........................................................................ 8 IV. SUMMARY OF PRIOR ART .....................................................................
    [Show full text]
  • Use of HTTP State Management RFC 2964
    Network Working Group K. Moore Request for Comments: 2964 University of Tennessee BCP: 44 N. Freed Category: Best Current Practice Innosoft October 2000 Use of HTTP State Management Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. IESG Note The IESG notes that this mechanism makes use of the .local top-level domain (TLD) internally when handling host names that don't contain any dots, and that this mechanism might not work in the expected way should an actual .local TLD ever be registered. Abstract The mechanisms described in "HTTP State Management Mechanism" (RFC- 2965), and its predecessor (RFC-2109), can be used for many different purposes. However, some current and potential uses of the protocol are controversial because they have significant user privacy and security implications. This memo identifies specific uses of Hypertext Transfer Protocol (HTTP) State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification. 1. Introduction The HTTP State Management mechanism is both useful and controversial. It is useful because numerous applications of HTTP benefit from the ability to save state between HTTP transactions, without encoding such state in URLs. It is controversial because the mechanism has been used to accomplish things for which it was not designed and is not well-suited.
    [Show full text]
  • HTTP Cookies: Standards, Privacy, and Politics
    HTTP Cookies: Standards, Privacy, and Politics DAVID M. KRISTOL Bell Labs, Lucent Technologies How did we get from a world where cookies were something you ate and where “nontechies” were unaware of “Netscape cookies” to a world where cookies are a hot-button privacy issue for many computer users? This article describes how HTTP “cookies” work and how Netscape’s original specification evolved into an IETF Proposed Standard. I also offer a personal perspective on how what began as a straightforward technical specification turned into a political flashpoint when it tried to address nontechnical issues such as privacy. Categories and Subject Descriptors: C.2.2 [Computer-Communication Networks]: Network Protocols—Applications; K.2 [History of Computing]: Systems General Terms: Standardization, Security, Design Additional Key Words and Phrases: Cookies, HTTP, privacy, state management, World Wide Web 1. INTRODUCTION The topic of HTTP “cookies” has become at least slightly familiar to many In- ternet users. Articles in the popular press now regularly mention cookies in conjunction with privacy concerns. However, cookies were in use for over two years before they achieved notoriety,and some of that notoriety emerged around the same time as the appearance of the first formal standard for cookies, which had previously been informally described on Netscape Communications Corpo- ration’s Web site. The cookie standardization process began in April 1995 with a discussion on [www-talk]. In December of that year, the IETF undertook to write a cookie standard. After a series of Internet-Drafts got published in connec- tion with extensive public discussion on [http-wg] (and after noticeable de- lays due to IETF process), RFC 2109 [Kristol and Montulli 1997], HTTP State Management Mechanism, was published in February 1997 as an IETF Pro- posed Standard.
    [Show full text]
  • Kapanfangrechts
    KapAnfangRechts Literaturverzeichnis 1. Marc Abrams, Charles R. Standridge, Ghaleb Abdulla, Stephen Williams und Edward A. Fox. Caching Proxies: Limitations and Potentials. In Proceedings of the Fourth International World Wide Web Conference, S. 119–133, Boston, Massachu- setts, Dezember 1995. 2. Adobe Systems Inc. Postscript Language Reference Manual. Addison-Wesley, Reading, Massachusetts, 2. Auflage, Dezember 1990. 3. Adobe Systems Inc. Postscript Language Reference Manual. Addison-Wesley, Reading, Massachusetts, 3. Auflage, Januar 1999. 4. Nabeel AI-Shamma, Robert Ayers, Richard Cohn, Jon Ferraiolo, Martin Newell, Roger K. de Bry, Kevin McCluskey und Jerry Evans. Precision Graphics Markup Language (PGML). World Wide Web Consortium, Note NOTE-PGML-19980410, April 1998. 5. Paul Albitz und Cricket Liu. DNS and BIND. O'Reilly & Associates, Inc., Sebastopol, California, Januar 1992. 6. Aldus Corporation. TIFF – Revision 6.0. Seattle, Washington, Juni 1992. 7. Harald Tveit Alvestrand. Tags for the Identification of Languages. Internet proposed standard RFC 1766, März 1995. 8. American National Standards Institute. Coded Character Set – 7-Bit American National Standard Code for Information Interchange. ANSI X3.4, 1992. 9. American National Standards Institute. Information Retrieval (Z39.50): Applica- tion Service Definition and Protocol Specification. ANSI/NISO Z39.501995, Juli 1995. 10. Mark Andrews. Negative Caching of DNS Queries (DNS NCACHE). Internet proposed standard RFC 2308, März 1998. 11. Farhad Anklesaria, Mark McCahill, Paul Lindner, David Johnson, Daniel Torrey und Bob Alberti. The Internet Gopher Protocol. Internet informational RFC 1436, März 1993. 12. Apple Computer, Inc., Cupertino, California. The TrueType Reference Manual, Oktober 1996. 13. Helen Ashman und Paul Thistlewaite, Herausgeber. Proceedings of the Seventh International World Wide Web Conference, Brisbane, Australia, April 1998.
    [Show full text]
  • 2956 Surfnet Expertisecentrum Bv Category: Informational October 2000
    Network Working Group M. Kaat Request for Comments: 2956 SURFnet ExpertiseCentrum bv Category: Informational October 2000 Overview of 1999 IAB Network Layer Workshop Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet. Different technical scenarios for the (foreseeable) future and the impact of external influences were studied. This report lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. Table of Contents 1. Introduction . 2 2. Conclusions and Observations . 3 2.1 Transparency. 3 2.2 NAT, Application Level Gateways & Firewalls . 4 2.3 Identification and Addressing . 4 2.4 Observations on Address Space . 5 2.5 Routing Issues. 5 2.6 Observations on Mobility. 6 2.7 DNS Issues. 7 2.8 NAT and RSIP. 7 2.9 NAT, RSIP and IPv6. 8 2.10 Observations on IPv6. 9 3. Recommendations. 10 3.1 Recommendations on Namespace . 10 3.2 Recommendations on RSIP. 10 3.3 Recommendations on IPv6. 10 3.4 Recommendations on IPsec . 11 Kaat Informational [Page 1] RFC 2956 1999 IAB Network Layer Workshop October 2000 3.5 Recommendations on DNS .
    [Show full text]
  • 2765 Sun Microsystems Category: Standards Track February 2000
    Network Working Group E. Nordmark Request for Comments: 2765 Sun Microsystems Category: Standards Track February 2000 Stateless IP/ICMP Translation Algorithm (SIIT) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in [TRANS-MECH]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes". This new algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts. The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts. Acknowledgements This document is a product of the NGTRANS working group. Some text has been extracted from an old Internet Draft titled "IPAE: The SIPP Interoperability and Transition Mechanism" authored by R. Gilligan, E. Nordmark, and B. Hinden. George Tsirtsis provides the figures for Section 1. Keith Moore provided a careful review of the document. Nordmark Standards Track [Page 1] RFC 2765 SIIT February 2000 Table of Contents 1. Introduction and Motivation.............................. 2 1.1. Applicability and Limitations......................
    [Show full text]
  • 3834 University of Tennessee Category: Standards Track August 2004
    Network Working Group K. Moore Request for Comments: 3834 University of Tennessee Category: Standards Track August 2004 Recommendations for Automatic Responses to Electronic Mail Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders. The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders. 1. Introduction Many programs which automatically respond to email are currently in use. Although these programs vary widely in their function, several problems with this class of programs have been observed, including: significant numbers of useless or unwanted response and responses sent to inappropriate addresses, and occasional incidences of mail loops or "sorcerer's apprentice" mode.
    [Show full text]
  • Arxiv:Cs/0105018V1 [Cs.SE] 9 May 2001
    · 1 Contents 1 Introduction 3 2 What are Cookies? Why are they Useful? 4 2.1 An Introduction to Hypertext Transfer Protocol (HTTP) . ..... 4 2.2 HowDoCookiesWork? ......................... 5 2.3 Proxies................................... 6 2.4 WhyCookies?............................... 6 2.5 HowAreCookiesUsed? ......................... 7 3 The IETF Standards Process 8 4 RFCs2109and2965:ABriefHistory 9 4.1 IntheBeginning... ........................... 9 4.2 RFC 2109: December, 1995to February,1997 . 10 4.3 RFC2965: February,1997toOctober,2000 . 12 4.3.1 Fixing the Incompatibility . 12 4.3.2 Unverifiable Transactions and Certified Cookies . ... 12 4.3.3 DeadlockandResolution . 12 5 Privacy/Politics 13 5.1 FederalTradeCommission. 13 5.2 W3CandP3P .............................. 14 5.3 IndustrySelf-Regulation . 14 5.4 Third-PartyCookies . .. .. .. .. .. .. .. .. .. .. .. 14 5.5 DoUsersCare?.............................. 15 6 Lessons Learned 16 6.1 WritingStandardsIsHard. 16 6.2 ZombieTopics .............................. 16 6.3 ReconcilingIncompatibleGoals . 17 6.3.1 Domain-matchingRules . 17 6.3.2 Compatibility and Deployment . 17 arXiv:cs/0105018v1 [cs.SE] 9 May 2001 6.4 SpeakNow,orForeverHoldYourPeace . 17 6.5 How Wide is the World Wide Web? . 18 6.6 Technical Decisions May Have Social Consequences . ..... 18 6.7 HowtoDoitBetter ........................... 19 6.7.1 Involvethestakeholders . 19 6.7.2 Separatepolicyandmechanism . 19 6.7.3 Avoidlily-gilding. 20 7 Conclusions 20 7.1 TimingMatters.............................. 20 7.2 OntheBrightSide... .......................... 21 7.3 Summary ................................. 22 7.4 WhyDidIStickWithIt? ........................ 22 2 · David M. Kristol 8 Acknowledgements 22 Appendix 24 A History of RFC 2109, HTTP State Management Mechanism 24 A.1 TheStateSub-GroupForms. 24 A.2 TechnicalDetails: Netscape’sCookies . ... 25 A.2.1 Server to Client: Set-Cookie .................. 25 A.2.2 Client to Server: Cookie ....................
    [Show full text]
  • Jay P. Kesan* & R
    ARTICLE DECONSTRUCTING CODE JAY P. KESAN* & RAJIV C. SHAH** I. INTRODUCTION ............................................................................. 279 II. THE CASE STUDIES: THE DEVELOPMENT OF CODE WITHIN INSTITUTIONS ...................................................... 289 A. WORLD WIDE WEB .......................................................... 290 1. LIBWWW............................................................................ 290 2. NCSA MOSAIC ................................................................. 292 B. COOKIES ............................................................................ 297 1. NETSCAPE’S COOKIES....................................................... 297 2. THE IETF’S STANDARD FOR COOKIES............................ 301 C. PLATFORM FOR INTERNET CONTENT SELECTION ......... 305 D. APACHE ............................................................................. 311 III. LEGISLATIVE BODIES: SOCIETAL INSTITUTIONS THAT DEVELOP CODE.................................................................. 314 A. UNIVERSITIES .................................................................... 315 B. FIRMS................................................................................. 318 C. CONSORTIA ....................................................................... 320 D. OPEN SOURCE MOVEMENT.............................................. 325 IV. CAMPAIGN CONTRIBUTIONS AND SPECIAL INTERESTS: INFLUENCES THAT SHAPE THE DEVELOPMENT OF CODE ......... 328 A. UNIVERSITIES ...................................................................
    [Show full text]