DOCSLIB.ORG

Hypertext Transfer Protocol -- HTTP/1.1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Hypertext Transfer Protocol -- HTTP/1.1 Network Working Group R. Fielding Request for Comments: 2616 UC Irvine Obsoletes: 2068 J. Gettys Category: Standards Track Compaq/W3C J. C. Mogul Compaq H. Frystyk W3C/MIT L. Masinter Xerox P. Leach Microsoft T. Berners-Lee W3C/MIT June, 1999 Hypertext Transfer Protocol -- HTTP/1.1 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 (1999). All Rights Reserved. Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as “HTTP/1.1”, and is an update to RFC 2068 [33]. Fielding, et al Standards Track [Page 1] RFC 2616 HTTP/1.1 June, 1999 Table of Contents HYPERTEXT TRANSFER PROTOCOL -- HTTP/1.1.................................................1 Status of this Memo .......................................................................................................................................1 Copyright Notice............................................................................................................................................1 Abstract ..........................................................................................................................................................1 Table of Contents...........................................................................................................................................2 1 Introduction .......................................................................................................................................7 1.1 Purpose ........................................................................................................................................7 1.2 Requirements ...............................................................................................................................7 1.3 Terminology ................................................................................................................................8 1.4 Overall Operation ......................................................................................................................10 2 Notational Conventions and Generic Grammar ...........................................................................11 2.1 Augmented BNF........................................................................................................................11 2.2 Basic Rules ................................................................................................................................12 3 Protocol Parameters ........................................................................................................................13 3.1 HTTP Version ...........................................................................................................................13 3.2 Uniform Resource Identifiers.....................................................................................................14 3.2.1 General Syntax...................................................................................................................14 3.2.2 http URL ............................................................................................................................14 3.2.3 URI Comparison................................................................................................................15 3.3 Date/Time Formats ....................................................................................................................15 3.3.1 Full Date ............................................................................................................................15 3.3.2 Delta Seconds ....................................................................................................................16 3.4 Character Sets ............................................................................................................................16 3.4.1 Missing Charset .................................................................................................................16 3.5 Content Codings ........................................................................................................................16 3.6 Transfer Codings .......................................................................................................................17 3.6.1 Chunked Transfer Coding..................................................................................................18 3.7 Media Types ..............................................................................................................................18 3.7.1 Canonicalization and Text Defaults...................................................................................19 3.7.2 Multipart Types..................................................................................................................19 3.8 Product Tokens..........................................................................................................................20 3.9 Quality Values ...........................................................................................................................20 3.10 Language Tags...........................................................................................................................20 3.11 Entity Tags.................................................................................................................................20 3.12 Range Units ...............................................................................................................................21 4 HTTP Message.................................................................................................................................21 4.1 Message Types...........................................................................................................................21 4.2 Message Headers .......................................................................................................................21 4.3 Message Body............................................................................................................................22 4.4 Message Length .........................................................................................................................23 4.5 General Header Fields ...............................................................................................................23 Fielding, et al Standards Track [Page 2] RFC 2616 HTTP/1.1 June, 1999 5 Request .............................................................................................................................................24 5.1 Request-Line..............................................................................................................................24 5.1.1 Method...............................................................................................................................24 5.1.2 Request-URI ......................................................................................................................24 5.2 The Resource Identified by a Request .......................................................................................25 5.3 Request Header Fields ...............................................................................................................26 6 Response ...........................................................................................................................................26 6.1 Status-Line.................................................................................................................................26 6.1.1 Status Code and Reason Phrase .........................................................................................26 6.2 Response Header Fields.............................................................................................................28 7 Entity ................................................................................................................................................28 7.1 Entity Header Fields ..................................................................................................................28 7.2 Entity Body................................................................................................................................29 7.2.1 Type...................................................................................................................................29 7.2.2 Entity Length .....................................................................................................................29 8 Connections ......................................................................................................................................29
Load more

Recommended publications
  • Architecture of the World Wide Web, First Edition Editor's Draft 14 October 2004
    Architecture of the World Wide Web, First Edition Editor's Draft 14 October 2004 This version: http://www.w3.org/2001/tag/2004/webarch-20041014/ Latest editor's draft: http://www.w3.org/2001/tag/webarch/ Previous version: http://www.w3.org/2001/tag/2004/webarch-20040928/ Latest TR version: http://www.w3.org/TR/webarch/ Editors: Ian Jacobs, W3C Norman Walsh, Sun Microsystems, Inc. Authors: See acknowledgments (§8, pg. 42). Copyright © 2002-2004 W3C ® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements. Abstract The World Wide Web is an information space of interrelated resources. This information space is the basis of, and is shared by, a number of information systems. In each of these systems, people and software retrieve, create, display, analyze, relate, and reason about resources. The World Wide Web uses relatively simple technologies with sufficient scalability, efficiency and utility that they have resulted in a remarkable information space of interrelated resources, growing across languages, cultures, and media. In an effort to preserve these properties of the information space as the technologies evolve, this architecture document discusses the core design components of the Web. They are identification of resources, representation of resource state, and the protocols that support the interaction between agents and resources in the space. We relate core design components, constraints, and good practices to the principles and properties they support. Status of this document This section describes the status of this document at the time of its publication.
    [Show full text]
  • Ipsec, SSL, Firewall, Wireless Security
    IPSec 1 Outline • Internet Protocol – IPv6 • IPSec – Security Association (SA) – IPSec Base Protocol (AH, ESP) – Encapsulation Mode (transport, tunnel) 2 IPv6 Header • Initial motivation: – 32-bit address space soon to be completely allocated. – Expands addresses to 128 bits • 430,000,000,000,000,000,000 for every square inch of earth’s surface! • Solves IPv4 problem of insufficient address space • Additional motivation: – header format helps speedy processing/forwarding – header changes to facilitate QoS IPv6 datagram format: – fixed-length 40 byte header – no fragmentation allowed 3 IPv6 Header (Cont) Priority: identify priority among datagrams in flow Flow Label: identify datagrams in same “flow.” (concept of“flow” not well defined). Next header: identify upper layer protocol for data 4 Other Changes from IPv4 • Checksum: removed entirely to reduce processing time at each hop • Options: allowed, but outside of header, indicated by “Next Header” field • ICMPv6: new version of ICMP – additional message types, e.g. “Packet Too Big” – multicast group management functions 5 IPv6 Security – IPsec mandated • IPsec is mandated in IPv6 – This means that all implementations (i.e. hosts, routers, etc) must have IPsec capability to be considered as IPv6-conformant • When (If?) IPv6 is in widespread use, this means that IPsec will be installed everywhere – At the moment, IPsec is more common in network devices (routers, etc) than user hosts, but this would change with IPsec • All hosts having IPsec => real end-to-end security possible 6 IPv6 Security • Enough IP addrs for every imaginable device + Real end-to-end security = Ability to securely communicate from anything to anything 7 IPv6 Security – harder to scan networks • With IPv4, it is easy to scan a network – With tools like nmap, can scan a typical subnet in a few minutes see: http://www.insecure.org/nmap/ – Returning list of active hosts and open ports – Many worms also operate by scanning • e.g.
    [Show full text]
  • Dynamic Web Pages with the Embedded Web Server
    Dynamic Web Pages With The Embedded Web Server The Digi-Geek’s AJAX Workbook (NET+OS, XML, & JavaScript) Version 1.0 5/4/2011 Page 1 Copyright Digi International, 2011 Table of Contents Chapter 1 - How to Use this Guide ............................................................................................................... 5 Prerequisites – If You Can Ping, You Can Use This Thing! ..................................................................... 5 Getting Help with TCP/IP and Wi-Fi Setup ............................................................................................ 5 The Study Guide or the Short Cut? ....................................................................................................... 5 C Code ................................................................................................................................................... 6 HTML Code ............................................................................................................................................ 6 XML File ................................................................................................................................................. 6 Provide us with Your Feedback ............................................................................................................. 6 Chapter 2 - The Server-Client Relationship ................................................................................................... 7 Example – An Analogy for a Normal HTML page .................................................................................
    [Show full text]
  • Spring Form Tag Library
    Spring Form Tag Library The Spring Web MVC framework provides a set of tags in the form of a tag library, which is used to construct views (web pages). The Spring Web MVC integrates Spring's form tag library. Spring's form tag accesses to the command object, and also it refers to the data our Spring controller deals with. A Command object can be defined as a JavaBean that stores user input, usually entered through HTML form is called the Command object. The Spring form tag makes it easier to develop, maintain, and read JSPs. The Spring form tags are used to construct user interface elements such as text and buttons. Spring form tag library has a set of tags such as <form> and <input>. Each form tag provides support for the set of attributes of its corresponding HTML tag counterpart, which allows a developer to develop UI components in JSP or HTML pages. Configuration – spring-form.tld The Spring form tag library comes bundled in spring-webmvc.jar. The spring- form.tld is known as Tag Library Descriptor (tld) file, which is available in a web application and generates HTML tags. The Spring form tag library must be defined at the top of the JSP page. The following directive needs to be added to the top of your JSP pages, in order to use Spring form tags from this library: <%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %> Here, form is the tag name prefix, which will be used for the tags from this Spring form tag library in JSP pages.
    [Show full text]
  • Lesson 1 Key-Terms Meanings: Internet Connectivity Principles
    Lesson 1 Key-Terms Meanings: Internet Connectivity Principles Chapter-4 L01: "Internet of Things " , Raj Kamal, 2017 1 Publs.: McGraw-Hill Education Header Words • Header words are placed as per the actions required at succeeding stages during communication from Application layer • Each header word at a layer consists of one or more header fields • The header fields specify the actions as per the protocol used Chapter-4 L01: "Internet of Things " , Raj Kamal, 2017 2 Publs.: McGraw-Hill Education Header fields • Fields specify a set of parameters encoded in a header • Parameters and their encoding as per the protocol used at that layer • For example, fourth word header field for 32-bit Source IP address in network layer using IP Chapter-4 L01: "Internet of Things " , Raj Kamal, 2017 3 Publs.: McGraw-Hill Education Protocol Header Field Example • Header field means bits in a header word placed at appropriate bit place, for example, place between bit 0 and bit 31 when a word has 32-bits. • First word fields b31-b16 for IP packet length in bytes, b15-b4 Service type and precedence and b3-b0 for IP version • Chapter-4 L01: "Internet of Things " , Raj Kamal, 2017 4 Publs.: McGraw-Hill Education IP Header • Header fields consist of parameters and their encodings which are as per the IP protocol • An internet layer protocol at a source or destination in TCP/IP suite of protocols Chapter-4 L01: "Internet of Things " , Raj Kamal, 2017 5 Publs.: McGraw-Hill Education TCP Header • Header fields consist of parameters and their encoding which are as
    [Show full text]
  • SILC-A SECURED INTERNET CHAT PROTOCOL Anindita Sinha1, Saugata Sinha2 Asst
    ISSN (Print) : 2320 – 3765 ISSN (Online): 2278 – 8875 International Journal of Advanced Research in Electrical, Electronics and Instrumentation Engineering Vol. 2, Issue 5, May 2013 SILC-A SECURED INTERNET CHAT PROTOCOL Anindita Sinha1, Saugata Sinha2 Asst. Prof, Dept. of ECE, Siliguri Institute of Technology, Sukna, Siliguri, West Bengal, India 1 Network Engineer, Network Dept, Ericsson Global India Ltd, India2 Abstract:-. The Secure Internet Live Conferencing (SILC) protocol, a new generation chat protocol provides full featured conferencing services, compared to any other chat protocol. Its main interesting point is security which has been described all through the paper. We have studied how encryption and authentication of the messages in the network achieves security. The security has been the primary goal of the SILC protocol and the protocol has been designed from the day one security in mind. In this paper we have studied about different keys which have been used to achieve security in the SILC protocol. The main function of SILC is to achieve SECURITY which is most important in any chat protocol. We also have studied different command for communication in chat protocols. Keywords: SILC protocol, IM, MIME, security I.INTRODUCTION SILC stands for “SECURE INTERNET LIVE CONFERENCING”. SILC is a secure communication platform, looks similar to IRC, first protocol & quickly gained the status of being the most popular chat on the net. The security is important feature in applications & protocols in contemporary network environment. It is not anymore enough to just provide services; they need to be secure services. The SILC protocol is a new generation chat protocol which provides full featured conferencing services; additionally it provides security by encrypting & authenticating the messages in the network.
    [Show full text]
  • Supplement 211: Dicomweb Support for the Application/Zip Payload
    5 Digital Imaging and Communications in Medicine (DICOM) Supplement 211: 10 DICOMweb Support for the application/zip Payload 15 20 Prepared by: Bill Wallace, Brad Genereaux DICOM Standards Committee, Working Group 27 1300 N. 17th Street Rosslyn, Virginia 22209 USA 25 Developed in accordance with work item WI 2018 -09 -C VERSION: 19 January 16, 2020 Table of Contents Scope and Field of Application ........................................................................................................................................ iii 30 Open Questions ....................................................................................................................................................... iii Closed Questions .................................................................................................................................................... iiii 8.6.1.3.1 File Extensions ................................................................................................................................. viv 8.6.1.3.2 BulkData URI ................................................................................................................................... viv 8.6.1.3.3 Logical Format ........................................................................................................................................ viv 35 8.6.1.3.4 Metadata Representations ...................................................................................................................... viv Scope and Field of Application
    [Show full text]
  • Rdfa in XHTML: Syntax and Processing Rdfa in XHTML: Syntax and Processing
    RDFa in XHTML: Syntax and Processing RDFa in XHTML: Syntax and Processing RDFa in XHTML: Syntax and Processing A collection of attributes and processing rules for extending XHTML to support RDF W3C Recommendation 14 October 2008 This version: http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014 Latest version: http://www.w3.org/TR/rdfa-syntax Previous version: http://www.w3.org/TR/2008/PR-rdfa-syntax-20080904 Diff from previous version: rdfa-syntax-diff.html Editors: Ben Adida, Creative Commons [email protected] Mark Birbeck, webBackplane [email protected] Shane McCarron, Applied Testing and Technology, Inc. [email protected] Steven Pemberton, CWI Please refer to the errata for this document, which may include some normative corrections. This document is also available in these non-normative formats: PostScript version, PDF version, ZIP archive, and Gzip’d TAR archive. The English version of this specification is the only normative version. Non-normative translations may also be available. Copyright © 2007-2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply. Abstract The current Web is primarily made up of an enormous number of documents that have been created using HTML. These documents contain significant amounts of structured data, which is largely unavailable to tools and applications. When publishers can express this data more completely, and when tools can read it, a new world of user functionality becomes available, letting users transfer structured data between applications and web sites, and allowing browsing applications to improve the user experience: an event on a web page can be directly imported - 1 - How to Read this Document RDFa in XHTML: Syntax and Processing into a user’s desktop calendar; a license on a document can be detected so that users can be informed of their rights automatically; a photo’s creator, camera setting information, resolution, location and topic can be published as easily as the original photo itself, enabling structured search and sharing.
    [Show full text]
  • Web Services Security Using SOAP, \Rysdl and UDDI
    Web Services Security Using SOAP, \rySDL and UDDI by Lin Yan A Thesis Submitted to the Faculty of Graduate Studies in Partial Fulfillment of the Requirements for the Degtee of MASTER OF SCIENCE Department of Electrical and Computer Engineering University of Manitoba Winnipeg, Manitoba, Canada @ Lin Yan, 2006 THE I]NTVERSITY OF MANITOBA FACULTY OF GRÄDUATE STUDIES COPYRIGHT PERMISSION Web Services Security Using SOAP, WSDL and IJDDI BY Lin Yan A Thesis/Practicum submitted to the Faculty ofGraduate Studies ofThe University of Manitoba in partial fulfillment of the requirement of the degree OF MASTER OF SCIENCE Lin Yan @ 2006 Permission has been granted to the Library ofthe University of Manitoba to lend or sell copies of this thesis/practicum' to the National Library of Canada to microfilm this thesis and to lend or sell copies of the film, and to University Microfitms Inc, to publish an abstract of this thesis/practicum, This reproduction or copy ofthis thesis has been made available by authority ofthe copyright orvner solely for the purpose of private study and research, and may only be reproduced and copied as permitted by copyright laws or with express rvritten authorization from the copyright owner. ABSTRACT The Internet is beginning to change the way businesses operate. Companies are using the Web for selling products, to find suppliers or trading partners, and to link existing applications to other applications. With the rise of today's e-business and e-commerce systems, web services are rapidly becoming the enabling technology to meet the need of commerce. However, they are not without problems.
    [Show full text]
  • Network Working Group N. Freed Request for Comments: 2049 Innosoft Obsoletes: 1521, 1522, 1590 N
    Network Working Group N. Freed Request for Comments: 2049 Innosoft Obsoletes: 1521, 1522, 1590 N. Borenstein Category: Standards Track First Virtual November 1996 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 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. Abstract STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. The second document defines the general structure of the MIME media typing system and defines an initial set of media types.
    [Show full text]
  • The Evolution of Lisp
    1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp.
    [Show full text]
  • The Cedar Programming Environment: a Midterm Report and Examination
    The Cedar Programming Environment: A Midterm Report and Examination Warren Teitelman The Cedar Programming Environment: A Midterm Report and Examination Warren Teitelman t CSL-83-11 June 1984 [P83-00012] © Copyright 1984 Xerox Corporation. All rights reserved. CR Categories and Subject Descriptors: D.2_6 [Software Engineering]: Programming environments. Additional Keywords and Phrases: integrated programming environment, experimental programming, display oriented user interface, strongly typed programming language environment, personal computing. t The author's present address is: Sun Microsystems, Inc., 2550 Garcia Avenue, Mountain View, Ca. 94043. The work described here was performed while employed by Xerox Corporation. XEROX Xerox Corporation Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, California 94304 1 Abstract: This collection of papers comprises a report on Cedar, a state-of-the-art programming system. Cedar combines in a single integrated environment: high-quality graphics, a sophisticated editor and document preparation facility, and a variety of tools for the programmer to use in the construction and debugging of his programs. The Cedar Programming Language is a strongly-typed, compiler-oriented language of the Pascal family. What is especially interesting about the Ce~ar project is that it is one of the few examples where an interactive, experimental programming environment has been built for this kind of language. In the past, such environments have been confined to dynamically typed languages like Lisp and Smalltalk. The first paper, "The Roots of Cedar," describes the conditions in 1978 in the Xerox Palo Alto Research Center's Computer Science Laboratory that led us to embark on the Cedar project and helped to define its objectives and goals.
    [Show full text]