Changeset 1717
- Timestamp:
- 05/07/12 04:02:58 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p0-introduction.xml
r1697 r1717 17 17 <!ENTITY ID-YEAR "2012"> 18 18 <!ENTITY mdash "—"> 19 <!ENTITY status-codes "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 21 ]> 20 22 <?rfc toc="yes" ?> … … 96 98 <abstract> 97 99 <t> 98 <cref>TODO</cref> 100 This document is the first in a series that, collectively, define the 101 HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1. 99 102 </t> 100 103 </abstract> … … 118 121 </front> 119 122 <middle> 120 <section title="Introduction" anchor="introduction"> 121 <t> 122 <cref>TODO</cref> 123 </t> 123 124 <section title="Introduction to the HTTP Document Series"> 125 <t> 126 This document is the first in a series that, collectively, define 127 the HyperText Transfer Protocol, version 1.1; otherwise known as 128 HTTP/1.1. 129 </t> 130 <t>The document series is organised as follows:</t> 131 <t><list style="symbols"> 132 <t>HTTP/1.1 Introduction - this document</t> 133 <t><xref target="Part1"/> HTTP/1.1 Message Parsing and Connection Handling 134 - How to parse a HTTP/1.1 (or below) message, and layer it onto 135 connection-oriented protocols.</t> 136 <t><xref target="Part2"/> HTTP/1.1 Core Semantics - Protocol elements such 137 as methods, status codes, and payload-specific headers. Also includes 138 content negotiation mechanisms.</t> 139 <t><xref target="Part4"/> HTTP/1.1 Conditional Requests - An extension to 140 make requests contingent upon their current state.</t> 141 <t><xref target="Part5"/> HTTP/1.1 Partial Content - An extension to 142 request that only a portion of a response be sent back.</t> 143 <t><xref target="Part6"/> HTTP/1.1 Caching - An extension to allow storage 144 and reuse of responses.</t> 145 <t><xref target="Part7"/> HTTP/1.1 Authentication Framework - extension 146 enabling client authentication to proxy and origin servers</t> 147 </list></t> 148 149 <t>The "core" of HTTP/1.1 is defined by the first two specifications. The 150 remaining specifications in the series are generally optional, but may be 151 required in some implementation or deployment scenarios; when this is the 152 case, it will be noted.</t> 153 154 <t>Collectively, these documents obsolete <xref target="RFC2616"/>. Note that 155 many other specifications extend and refine the use of HTTP (generally, as 156 protocol extensions, where allowed by these specifications); they are not 157 considered part of this series, but they are still "part of HTTP".</t> 158 124 159 </section> 160 161 <section title="What is HTTP?" anchor="wat"> 162 <t> 163 The Hypertext Transfer Protocol (HTTP) is an application-level 164 request/response protocol that uses extensible semantics and MIME-like 165 message payloads for flexible interaction with network-based hypertext 166 information systems. HTTP relies upon the Uniform Resource Identifier (URI) 167 standard <xref target="RFC3986"/> to indicate the target resource 168 and relationships between resources. 169 </t> 170 <t> 171 HTTP is a generic interface protocol for information systems. It is 172 designed to hide the details of how a service is implemented by presenting 173 a uniform interface to clients that is independent of the types of 174 resources provided. Likewise, servers do not need to be aware of each 175 client's purpose: an HTTP request can be considered in isolation rather 176 than being associated with a specific type of client or a predetermined 177 sequence of application steps. The result is a protocol that can be used 178 effectively in many different contexts and for which implementations can 179 evolve independently over time. 180 </t> 181 <t> 182 HTTP is also designed for use as an intermediation protocol for translating 183 communication to and from non-HTTP information systems. 184 HTTP proxies and gateways can provide access to alternative information 185 services by translating their diverse protocols into a hypertext 186 format that can be viewed and manipulated by clients in the same way 187 as HTTP services. 188 </t> 189 <t> 190 One consequence of HTTP flexibility is that the protocol cannot be 191 defined in terms of what occurs behind the interface. Instead, we 192 are limited to defining the syntax of communication, the intent 193 of received communication, and the expected behavior of recipients. 194 If the communication is considered in isolation, then successful 195 actions ought to be reflected in corresponding changes to the 196 observable interface provided by servers. However, since multiple 197 clients might act in parallel and perhaps at cross-purposes, we 198 cannot require that such changes be observable beyond the scope 199 of a single response. 200 </t> 201 <t> 202 <cref>TODO: remove corresponding text from p1 Introduction.</cref> 203 </t> 204 </section> 205 206 207 208 125 209 </middle> 126 210 <back> … … 255 339 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;" /> 256 340 <x:source basename="p7-auth" href="p7-auth.xml" /> 341 </reference> 342 343 <reference anchor="RFC3986"> 344 <front> 345 <title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title> 346 <author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'> 347 <organization abbrev="W3C/MIT">World Wide Web Consortium</organization> 348 <address> 349 <email>timbl@w3.org</email> 350 <uri>http://www.w3.org/People/Berners-Lee/</uri> 351 </address> 352 </author> 353 <author initials='R.' surname='Fielding' fullname='Roy T. Fielding'> 354 <organization abbrev="Day Software">Day Software</organization> 355 <address> 356 <email>fielding@gbiv.com</email> 357 <uri>http://roy.gbiv.com/</uri> 358 </address> 359 </author> 360 <author initials='L.' surname='Masinter' fullname='Larry Masinter'> 361 <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization> 362 <address> 363 <email>LMM@acm.org</email> 364 <uri>http://larry.masinter.net/</uri> 365 </address> 366 </author> 367 <date month='January' year='2005'></date> 368 </front> 369 <seriesInfo name="STD" value="66"/> 370 <seriesInfo name="RFC" value="3986"/> 257 371 </reference> 258 372 … … 297 411 </reference> 298 412 413 299 414 </references> 300 415 </back>
Note: See TracChangeset
for help on using the changeset viewer.