Changeset 1488 for draft-ietf-httpbis
- Timestamp:
- 05/12/11 22:51:33 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1481 r1488 359 359 } 360 360 @bottom-center { 361 content: "Expires June 3, 2012";361 content: "Expires June 7, 2012"; 362 362 } 363 363 @bottom-right { … … 409 409 <meta name="dct.creator" content="Reschke, J. F."> 410 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2011-12-0 1">411 <meta name="dct.issued" scheme="ISO8601" content="2011-12-05"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 413 413 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 441 441 </tr> 442 442 <tr> 443 <td class="left">Expires: June 3, 2012</td>443 <td class="left">Expires: June 7, 2012</td> 444 444 <td class="right">HP</td> 445 445 </tr> … … 494 494 <tr> 495 495 <td class="left"></td> 496 <td class="right">December 1, 2011</td>496 <td class="right">December 5, 2011</td> 497 497 </tr> 498 498 </tbody> … … 527 527 in progress”. 528 528 </p> 529 <p>This Internet-Draft will expire on June 3, 2012.</p>529 <p>This Internet-Draft will expire on June 7, 2012.</p> 530 530 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 531 531 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 879 879 "<dfn>sender</dfn>" to refer to whichever component sent a given message and the term "<dfn>recipient</dfn>" to refer to any component that receives the message. 880 880 </p> 881 <p id="rfc.section.2.1.p.3">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In 881 <div class="note" id="rfc.section.2.1.p.3"> 882 <p> <b>Note:</b> The term 'user agent' covers both those situations where there is a user (human) interacting with the software agent (and 883 for which user interface or interactive suggestions might be made, e.g., warning the user or given the user an option in the 884 case of security or privacy options) and also those where the software agent may act autonomously. 885 </p> 886 </div> 887 <p id="rfc.section.2.1.p.4">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In 882 888 the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and 883 889 the origin server (O). … … 889 895 <div id="rfc.iref.r.2"></div> 890 896 <div id="rfc.iref.r.3"></div> 891 <p id="rfc.section.2.1.p. 5">A client sends an HTTP request to the server in the form of a <dfn>request</dfn> message, beginning with a request-line that includes a method, URI, and protocol version (<a href="#request.line" title="Request-Line">Section 3.1.1</a>), followed by MIME-like header fields containing request modifiers, client information, and payload metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>).892 </p> 893 <p id="rfc.section.2.1.p. 6">A server responds to the client's request by sending an HTTP <dfn>response</dfn> message, beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase897 <p id="rfc.section.2.1.p.6">A client sends an HTTP request to the server in the form of a <dfn>request</dfn> message, beginning with a request-line that includes a method, URI, and protocol version (<a href="#request.line" title="Request-Line">Section 3.1.1</a>), followed by MIME-like header fields containing request modifiers, client information, and payload metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>). 898 </p> 899 <p id="rfc.section.2.1.p.7">A server responds to the client's request by sending an HTTP <dfn>response</dfn> message, beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase 894 900 (<a href="#status.line" title="Response Status-Line">Section 3.1.2</a>), followed by MIME-like header fields containing server information, resource metadata, and payload metadata (<a href="#header.fields" title="Header Fields">Section 3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section 3.3</a>). 895 901 </p> 896 <p id="rfc.section.2.1.p. 7">Note that 1xx responses (<a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) are not final; therefore, a server can send zero or more 1xx responses, followed by exactly one final response (with any902 <p id="rfc.section.2.1.p.8">Note that 1xx responses (<a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) are not final; therefore, a server can send zero or more 1xx responses, followed by exactly one final response (with any 897 903 other status code). 898 904 </p> 899 <p id="rfc.section.2.1.p. 8">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p>905 <p id="rfc.section.2.1.p.9">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p> 900 906 <div id="rfc.figure.u.10"></div> 901 907 <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1 … … 3479 3485 <p id="rfc.section.C.19.p.1">Closed issues: </p> 3480 3486 <ul> 3487 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/166">http://tools.ietf.org/wg/httpbis/trac/ticket/166</a>>: "Clarify 'User Agent'" 3488 </li> 3481 3489 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/300">http://tools.ietf.org/wg/httpbis/trac/ticket/300</a>>: "Define non-final responses" 3482 3490 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1481 r1488 536 536 message. 537 537 </t> 538 <x:note> 539 <t> 540 <x:h>Note:</x:h> The term 'user agent' covers both those situations where 541 there is a user (human) interacting with the software agent (and for which 542 user interface or interactive suggestions might be made, e.g., warning the 543 user or given the user an option in the case of security or privacy 544 options) and also those where the software agent may act autonomously. 545 </t> 546 </x:note> 538 547 <t> 539 548 Most HTTP communication consists of a retrieval request (GET) for … … 5866 5875 <list style="symbols"> 5867 5876 <t> 5877 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/166"/>: 5878 "Clarify 'User Agent'" 5879 </t> 5880 <t> 5868 5881 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/300"/>: 5869 5882 "Define non-final responses"
Note: See TracChangeset
for help on using the changeset viewer.