Ignore:
Timestamp:
26/03/12 14:21:18 (10 years ago)
Author:
julian.reschke@…
Message:

re-org sections

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1617 r1618  
    596596   information which will explain the unusual status.
    597597</t>
     598<t>
     599   The first digit of the status-code defines the class of response. The
     600   last two digits do not have any categorization role. There are 5
     601   values for the first digit:
     602  <list style="symbols">
     603    <t>
     604      1xx: Informational - Request received, continuing process
     605    </t>
     606    <t>
     607      2xx: Success - The action was successfully received,
     608        understood, and accepted
     609    </t>
     610    <t>
     611      3xx: Redirection - Further action needs to be taken in order to
     612        complete the request
     613    </t>
     614    <t>
     615      4xx: Client Error - The request contains bad syntax or cannot
     616        be fulfilled
     617    </t>
     618    <t>
     619      5xx: Server Error - The server failed to fulfill an apparently
     620        valid request
     621    </t>
     622  </list>
     623</t>
    598624
    599625<section title="Overview of Status Codes" anchor="overview.of.status.codes">
    … …  
    713739</section>
    714740
    715 </section>
    716 
    717 <section title="Representation" anchor="representation">
    718 <t>
    719    Request and Response messages &MAY; transfer a representation if not otherwise
    720    restricted by the request method or response status code. A representation
    721    consists of metadata (representation header fields) and data (representation
    722    body).  When a complete or partial representation is enclosed in an HTTP message,
    723    it is referred to as the payload of the message. HTTP representations
    724    are defined in &payload;.
    725 </t>
    726 <t>
    727    A representation body is only present in a message when a message body is
    728    present, as described in &message-body;. The representation body is obtained
    729    from the message body by decoding any Transfer-Encoding that might
    730    have been applied to ensure safe and proper transfer of the message.
    731 </t>
    732 
    733 <section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">
    734 <t>
    735    It is sometimes necessary to determine an identifier for the resource
    736    associated with a representation.
    737 </t>
    738 <t>
    739    An HTTP request representation, when present, is always associated with an
    740    anonymous (i.e., unidentified) resource.
    741 </t>
    742 <t>
    743    In the common case, an HTTP response is a representation of the target
    744    resource (see &effective-request-uri;). However, this is not always the
    745    case. To determine the URI of the resource a response is associated with,
    746    the following rules are used (with the first applicable one being selected):
    747 </t>
    748 <t><list style="numbers">
    749    <t>If the response status code is 200 or 203 and the request method was GET,
    750    the response payload is a representation of the target resource.</t>
    751    <t>If the response status code is 204, 206, or 304 and the request method was GET
    752    or HEAD, the response payload is a partial representation of the target
    753    resource.</t>
    754    <t>If the response has a Content-Location header field, and that URI is the same
    755    as the effective request URI, the response payload is a representation of the
    756    target resource.</t>
    757    <t>If the response has a Content-Location header field, and that URI is not the
    758    same as the effective request URI, then the response asserts that its
    759    payload is a representation of the resource identified by the
    760    Content-Location URI. However, such an assertion cannot be trusted unless
    761    it can be verified by other means (not defined by HTTP).</t>
    762    <t>Otherwise, the response is a representation of an anonymous (i.e.,
    763    unidentified) resource.</t>
    764 </list></t>
    765 <t>
    766   <cref anchor="TODO-req-uri">
    767    The comparison function is going to have to be defined somewhere,
    768    because we already need to compare URIs for things like cache invalidation.</cref>
    769 </t>
    770 </section>
    771 
    772 </section>
    773 
    774 
    775 <section title="Method Definitions" anchor="method.definitions">
    776 <t>
    777    The set of common request methods for HTTP/1.1 is defined below. Although
    778    this set can be expanded, additional methods cannot be assumed to
    779    share the same semantics for separately extended clients and servers.
    780 </t>
    781 
    782 <section title="Safe and Idempotent Methods" anchor="safe.and.idempotent">
    783 
    784 <section title="Safe Methods" anchor="safe.methods">
    785 <iref item="Safe Methods" primary="true"/>
    786 <t>
    787    Implementors need to be aware that the software represents the user in
    788    their interactions over the Internet, and need to allow
    789    the user to be aware of any actions they take which might have an
    790    unexpected significance to themselves or others.
    791 </t>
    792 <t>
    793    In particular, the convention has been established that the GET, HEAD,
    794    OPTIONS, and TRACE request methods &SHOULD-NOT; have the significance
    795    of taking an action other than retrieval. These request methods ought
    796    to be considered "<x:dfn anchor="safe">safe</x:dfn>".
    797    This allows user agents to represent other methods, such as POST, PUT
    798    and DELETE, in a special way, so that the user is made aware of the
    799    fact that a possibly unsafe action is being requested.
    800 </t>
    801 <t>
    802    Naturally, it is not possible to ensure that the server does not
    803    generate side-effects as a result of performing a GET request; in
    804    fact, some dynamic resources consider that a feature. The important
    805    distinction here is that the user did not request the side-effects,
    806    so therefore cannot be held accountable for them.
    807 </t>
    808 </section>
    809 
    810 <section title="Idempotent Methods" anchor="idempotent.methods">
    811 <iref item="Idempotent Methods" primary="true"/>
    812 <t>
    813    Request methods can also have the property of "idempotence" in that,
    814    aside from error or expiration issues, the intended effect of multiple
    815    identical requests is the same as for a single request.
    816    PUT, DELETE, and all safe request methods are idempotent.
    817    It is important to note that idempotence refers only to changes
    818    requested by the client: a server is free to change its state due
    819    to multiple requests for the purpose of tracking those requests,
    820    versioning of results, etc.
    821 </t>
    822 </section>
    823 </section>
    824 
    825 <section title="OPTIONS" anchor="OPTIONS">
    826   <rdf:Description>
    827     <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
    828   </rdf:Description>
    829   <iref primary="true" item="OPTIONS method" x:for-anchor=""/>
    830   <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/>
    831 <t>
    832    The OPTIONS method requests information about the
    833    communication options available on the request/response chain
    834    identified by the effective request URI. This method allows a client to
    835    determine the options and/or requirements associated with a resource,
    836    or the capabilities of a server, without implying a resource action
    837    or initiating a resource retrieval.
    838 </t>
    839 <t>
    840    Responses to the OPTIONS method are not cacheable.
    841 </t>
    842 <t>
    843    If the OPTIONS request includes a message body (as indicated by the
    844    presence of Content-Length or Transfer-Encoding), then the media type
    845    &MUST; be indicated by a Content-Type field. Although this
    846    specification does not define any use for such a body, future
    847    extensions to HTTP might use the OPTIONS body to make more detailed
    848    queries on the server.
    849 </t>
    850 <t>
    851    If the request-target (&request-target;) is an asterisk ("*"),
    852    the OPTIONS request is
    853    intended to apply to the server in general rather than to a specific
    854    resource. Since a server's communication options typically depend on
    855    the resource, the "*" request is only useful as a "ping" or "no-op"
    856    type of method; it does nothing beyond allowing the client to test
    857    the capabilities of the server. For example, this can be used to test
    858    a proxy for HTTP/1.1 conformance (or lack thereof).
    859 </t>
    860 <t>
    861    If the request-target is not an asterisk, the OPTIONS request applies
    862    only to the options that are available when communicating with that
    863    resource.
    864 </t>
    865 <t>
    866    A 200 response &SHOULD; include any header fields that indicate
    867    optional features implemented by the server and applicable to that
    868    resource (e.g., Allow), possibly including extensions not defined by
    869    this specification. The response body, if any, &SHOULD; also include
    870    information about the communication options. The format for such a
    871    body is not defined by this specification, but might be defined by
    872    future extensions to HTTP. Content negotiation &MAY; be used to select
    873    the appropriate response format. If no response body is included, the
    874    response &MUST; include a Content-Length field with a field-value of
    875    "0".
    876 </t>
    877 <t>
    878    The Max-Forwards header field &MAY; be used to target a
    879    specific proxy in the request chain (see <xref target="header.max-forwards"/>).
    880    If no Max-Forwards field is present in the request, then the forwarded
    881    request &MUST-NOT; include a Max-Forwards field.
    882 </t>
    883 </section>
    884 
    885 <section title="GET" anchor="GET">
    886   <rdf:Description>
    887     <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
    888   </rdf:Description>
    889   <iref primary="true" item="GET method" x:for-anchor=""/>
    890   <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/>
    891 <t>
    892    The GET method requests transfer of a current representation of
    893    the target resource.
    894 </t>
    895 <t>   
    896    If the target resource is a data-producing process, it is the
    897    produced data which shall be returned as the representation in the response and not
    898    the source text of the process, unless that text happens to be the output of
    899    the process.
    900 </t>
    901 <t>
    902    The semantics of the GET method change to a "conditional GET" if the
    903    request message includes an If-Modified-Since, If-Unmodified-Since,
    904    If-Match, If-None-Match, or If-Range header field. A conditional GET
    905    requests that the representation be transferred only under the
    906    circumstances described by the conditional header field(s). The
    907    conditional GET request is intended to reduce unnecessary network
    908    usage by allowing cached representations to be refreshed without requiring
    909    multiple requests or transferring data already held by the client.
    910 </t>
    911 <t>
    912    The semantics of the GET method change to a "partial GET" if the
    913    request message includes a Range header field. A partial GET requests
    914    that only part of the representation be transferred, as described in &header-range;.
    915    The partial GET request is intended to reduce unnecessary
    916    network usage by allowing partially-retrieved representations to be
    917    completed without transferring data already held by the client.
    918 </t>
    919 <t>
    920    Bodies on GET requests have no defined semantics. Note that sending a body
    921    on a GET request might cause some existing implementations to reject the
    922    request.
    923 </t>
    924 <t>
    925    The response to a GET request is cacheable and &MAY; be used to satisfy
    926    subsequent GET and HEAD requests (see &caching;).
    927 </t>
    928 <t>
    929    See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms.
    930 </t>
    931 </section>
    932 
    933 <section title="HEAD" anchor="HEAD">
    934   <rdf:Description>
    935     <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
    936   </rdf:Description>
    937   <iref primary="true" item="HEAD method" x:for-anchor=""/>
    938   <iref primary="true" item="Methods" subitem="HEAD" x:for-anchor=""/>
    939 <t>
    940    The HEAD method is identical to GET except that the server &MUST-NOT;
    941    return a message body in the response. The metadata contained
    942    in the HTTP header fields in response to a HEAD request &SHOULD; be identical
    943    to the information sent in response to a GET request. This method can
    944    be used for obtaining metadata about the representation implied by the
    945    request without transferring the representation body. This method is
    946    often used for testing hypertext links for validity, accessibility,
    947    and recent modification.
    948 </t>
    949 <t>
    950    The response to a HEAD request is cacheable and &MAY; be used to satisfy
    951    a subsequent HEAD request. It also has potential side effects on
    952    previously stored responses to GET; see &p6-head;.
    953 </t>
    954 <t>
    955    Bodies on HEAD requests have no defined semantics. Note that sending a body
    956    on a HEAD request might cause some existing implementations to reject the
    957    request.
    958 </t>
    959 </section>
    960 
    961 <section title="POST" anchor="POST">
    962   <iref primary="true" item="POST method" x:for-anchor=""/>
    963   <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/>
    964 <t>
    965    The POST method requests that the origin server accept the
    966    representation enclosed in the request as data to be processed by the
    967    target resource. POST is designed to allow a uniform method to cover the
    968    following functions:
    969   <list style="symbols">
    970     <t>
    971       Annotation of existing resources;
    972     </t>
    973     <t>
    974         Posting a message to a bulletin board, newsgroup, mailing list,
    975         or similar group of articles;
    976     </t>
    977     <t>
    978         Providing a block of data, such as the result of submitting a
    979         form, to a data-handling process;
    980     </t>
    981     <t>
    982         Extending a database through an append operation.
    983     </t>
    984   </list>
    985 </t>
    986 <t>
    987    The actual function performed by the POST method is determined by the
    988    server and is usually dependent on the effective request URI.
    989 </t>
    990 <t>
    991    The action performed by the POST method might not result in a
    992    resource that can be identified by a URI. In this case, either 200
    993    (OK) or 204 (No Content) is the appropriate response status code,
    994    depending on whether or not the response includes a representation that
    995    describes the result.
    996 </t>
    997 <t>
    998    If a resource has been created on the origin server, the response
    999    &SHOULD; be 201 (Created) and contain a representation which describes the
    1000    status of the request and refers to the new resource, and a Location
    1001    header field (see <xref target="header.location"/>).
    1002 </t>
    1003 <t>
    1004    Responses to POST requests are only cacheable when they
    1005    include explicit freshness information (see &p6-explicit;). A
    1006    cached POST response with a Content-Location header field
    1007    (see &header-content-location;) whose value is the effective
    1008    Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.
    1009 </t>
    1010 <t>
    1011    Note that POST caching is not widely implemented.
    1012    However, the 303 (See Other) response can be used to direct the
    1013    user agent to retrieve a cacheable representation of the resource.
    1014 </t>
    1015 </section>
    1016 
    1017 <section title="PUT" anchor="PUT">
    1018   <iref primary="true" item="PUT method" x:for-anchor=""/>
    1019   <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/>
    1020 <t>
    1021    The PUT method requests that the state of the target resource
    1022    be created or replaced with the state defined by the representation
    1023    enclosed in the request message payload.  A successful PUT of a given
    1024    representation would suggest that a subsequent GET on that same target
    1025    resource will result in an equivalent representation being returned in
    1026    a 200 (OK) response.  However, there is no guarantee that such a state
    1027    change will be observable, since the target resource might be acted
    1028    upon by other user agents in parallel, or might be subject to dynamic
    1029    processing by the origin server, before any subsequent GET is received.
    1030    A successful response only implies that the user agent's intent was
    1031    achieved at the time of its processing by the origin server.
    1032 </t>
    1033 <t>   
    1034    If the target resource does not have a current representation and
    1035    the PUT successfully creates one, then the origin server &MUST; inform
    1036    the user agent by sending a 201 (Created) response.  If the target
    1037    resource does have a current representation and that representation is
    1038    successfully modified in accordance with the state of the enclosed
    1039    representation, then either a 200 (OK) or 204 (No Content) response
    1040    &SHOULD; be sent to indicate successful completion of the request.
    1041 </t>
    1042 <t>
    1043    Unrecognized header fields &SHOULD; be ignored (i.e., not saved
    1044    as part of the resource state).
    1045 </t>
    1046 <t>
    1047    An origin server &SHOULD; verify that the PUT representation is
    1048    consistent with any constraints which the server has for the target
    1049    resource that cannot or will not be changed by the PUT.  This is
    1050    particularly important when the origin server uses internal
    1051    configuration information related to the URI in order to set the
    1052    values for representation metadata on GET responses.  When a PUT
    1053    representation is inconsistent with the target resource, the origin
    1054    server &SHOULD; either make them consistent, by transforming the
    1055    representation or changing the resource configuration, or respond
    1056    with an appropriate error message containing sufficient information
    1057    to explain why the representation is unsuitable.  The 409 (Conflict)
    1058    or 415 (Unsupported Media Type) status codes are suggested, with the
    1059    latter being specific to constraints on Content-Type values.
    1060 </t>
    1061 <t>
    1062    For example, if the target resource is configured to always have a
    1063    Content-Type of "text/html" and the representation being PUT has a
    1064    Content-Type of "image/jpeg", then the origin server &SHOULD; do one of:
    1065    (a) reconfigure the target resource to reflect the new media type;
    1066    (b) transform the PUT representation to a format consistent with that
    1067    of the resource before saving it as the new resource state; or,
    1068    (c) reject the request with a 415 response indicating that the target
    1069    resource is limited to "text/html", perhaps including a link to a
    1070    different resource that would be a suitable target for the new
    1071    representation.
    1072 </t>
    1073 <t>
    1074    HTTP does not define exactly how a PUT method affects the state
    1075    of an origin server beyond what can be expressed by the intent of
    1076    the user agent request and the semantics of the origin server response.
    1077    It does not define what a resource might be, in any sense of that
    1078    word, beyond the interface provided via HTTP.  It does not define
    1079    how resource state is "stored", nor how such storage might change
    1080    as a result of a change in resource state, nor how the origin server
    1081    translates resource state into representations.  Generally speaking,
    1082    all implementation details behind the resource interface are
    1083    intentionally hidden by the server.
    1084 </t>
    1085 <t>
    1086    The fundamental difference between the POST and PUT methods is
    1087    highlighted by the different intent for the target resource.
    1088    The target resource in a POST request is intended to handle the
    1089    enclosed representation as a data-accepting process, such as for
    1090    a gateway to some other protocol or a document that accepts annotations.
    1091    In contrast, the target resource in a PUT request is intended to
    1092    take the enclosed representation as a new or replacement value.
    1093    Hence, the intent of PUT is idempotent and visible to intermediaries,
    1094    even though the exact effect is only known by the origin server.
    1095 </t>
    1096 <t>
    1097    Proper interpretation of a PUT request presumes that the user agent
    1098    knows what target resource is desired.  A service that is intended
    1099    to select a proper URI on behalf of the client, after receiving
    1100    a state-changing request, &SHOULD; be implemented using the POST
    1101    method rather than PUT.  If the origin server will not make the
    1102    requested PUT state change to the target resource and instead
    1103    wishes to have it applied to a different resource, such as when the
    1104    resource has been moved to a different URI, then the origin server
    1105    &MUST; send a 301 (Moved Permanently) response; the user agent &MAY;
    1106    then make its own decision regarding whether or not to redirect the
    1107    request.
    1108 </t>
    1109 <t>
    1110    A PUT request applied to the target resource &MAY; have side-effects
    1111    on other resources.  For example, an article might have a URI for
    1112    identifying "the current version" (a resource) which is separate
    1113    from the URIs identifying each particular version (different
    1114    resources that at one point shared the same state as the current version
    1115    resource).  A successful PUT request on "the current version" URI might
    1116    therefore create a new version resource in addition to changing the
    1117    state of the target resource, and might also cause links to be added
    1118    between the related resources.
    1119 </t>
    1120 <t>
    1121    An origin server &SHOULD; reject any PUT request that contains a
    1122    Content-Range header field, since it might be misinterpreted as
    1123    partial content (or might be partial content that is being mistakenly
    1124    PUT as a full representation).  Partial content updates are
    1125    possible by targeting a separately identified resource with state
    1126    that overlaps a portion of the larger resource, or by using a
    1127    different method that has been specifically defined for partial
    1128    updates (for example, the PATCH method defined in
    1129    <xref target="RFC5789"/>).
    1130 </t>
    1131 <t>
    1132    Responses to the PUT method are not cacheable. If a PUT request passes
    1133    through a cache that has one or more stored responses for the effective
    1134    request URI, those stored responses will be invalidated (see
    1135    &p6-invalid;).
    1136 </t>
    1137 </section>
    1138 
    1139 <section title="DELETE" anchor="DELETE">
    1140   <iref primary="true" item="DELETE method" x:for-anchor=""/>
    1141   <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/>
    1142 <t>
    1143    The DELETE method requests that the origin server delete the target
    1144    resource. This method &MAY; be overridden by
    1145    human intervention (or other means) on the origin server. The client cannot
    1146    be guaranteed that the operation has been carried out, even if the
    1147    status code returned from the origin server indicates that the action
    1148    has been completed successfully. However, the server &SHOULD-NOT;
    1149    indicate success unless, at the time the response is given, it
    1150    intends to delete the resource or move it to an inaccessible
    1151    location.
    1152 </t>
    1153 <t>
    1154    A successful response &SHOULD; be 200 (OK) if the response includes an
    1155    representation describing the status, 202 (Accepted) if the action has not
    1156    yet been enacted, or 204 (No Content) if the action has been enacted
    1157    but the response does not include a representation.
    1158 </t>
    1159 <t>
    1160    Bodies on DELETE requests have no defined semantics. Note that sending a body
    1161    on a DELETE request might cause some existing implementations to reject the
    1162    request.
    1163 </t>
    1164 <t>
    1165    Responses to the DELETE method are not cacheable. If a DELETE request
    1166    passes through a cache that has one or more stored responses for the
    1167    effective request URI, those stored responses will be invalidated (see
    1168    &p6-invalid;).
    1169 </t>
    1170 </section>
    1171 
    1172 <section title="TRACE" anchor="TRACE">
    1173   <rdf:Description>
    1174     <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
    1175   </rdf:Description>
    1176   <iref primary="true" item="TRACE method" x:for-anchor=""/>
    1177   <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/>
    1178 <t>
    1179    The TRACE method requests a remote, application-layer loop-back
    1180    of the request message. The final recipient of the request
    1181    &SHOULD; reflect the message received back to the client as the
    1182    message body of a 200 (OK) response. The final recipient is either the
    1183    origin server or the first proxy to receive a Max-Forwards
    1184    value of zero (0) in the request (see <xref target="header.max-forwards"/>).
    1185    A TRACE request &MUST-NOT; include a message body.
    1186 </t>
    1187 <t>
    1188    TRACE allows the client to see what is being received at the other
    1189    end of the request chain and use that data for testing or diagnostic
    1190    information. The value of the Via header field (&header-via;) is of
    1191    particular interest, since it acts as a trace of the request chain.
    1192    Use of the Max-Forwards header field allows the client to limit the
    1193    length of the request chain, which is useful for testing a chain of
    1194    proxies forwarding messages in an infinite loop.
    1195 </t>
    1196 <t>
    1197    If the request is valid, the response &SHOULD; have a Content-Type of
    1198    "message/http" (see &media-type-message-http;) and contain a message body
    1199    that encloses a copy of the entire request message.
    1200    Responses to the TRACE method are not cacheable.
    1201 </t>
    1202 </section>
    1203 
    1204 <section title="CONNECT" anchor="CONNECT">
    1205   <iref primary="true" item="CONNECT method" x:for-anchor=""/>
    1206   <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/>
    1207 <t>
    1208    The CONNECT method requests that the proxy establish a tunnel
    1209    to the request-target and, if successful, thereafter restrict its behavior
    1210    to blind forwarding of packets until the connection is closed.
    1211 </t>
    1212 <t>
    1213    When using CONNECT, the request-target &MUST; use the authority form
    1214    (&request-target;); i.e., the request-target consists of only the
    1215    host name and port number of the tunnel destination, separated by a colon.
    1216    For example,
    1217 </t>
    1218 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    1219 CONNECT server.example.com:80 HTTP/1.1
    1220 Host: server.example.com:80
    1221 
    1222 </artwork></figure>
    1223 <t>
    1224    Any successful (2xx) response to a CONNECT request indicates that the
    1225    proxy has established a connection to the requested host and port,
    1226    and has switched to tunneling the current connection to that server
    1227    connection.
    1228    The tunneled data from the server begins immediately after the blank line
    1229    that concludes the successful response's header block.
    1230    A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length
    1231    header fields in a successful response.
    1232    A client &MUST; ignore any Content-Length or Transfer-Encoding header
    1233    fields received in a successful response.
    1234 </t>
    1235 <t>
    1236    Any response other than a successful response indicates that the tunnel
    1237    has not yet been formed and that the connection remains governed by HTTP.
    1238 </t>
    1239 <t>
    1240    Proxy authentication might be used to establish the
    1241    authority to create a tunnel:
    1242 </t>
    1243 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    1244 CONNECT server.example.com:80 HTTP/1.1
    1245 Host: server.example.com:80
    1246 Proxy-Authorization: basic aGVsbG86d29ybGQ=
    1247 
    1248 </artwork></figure>
    1249 <t>
    1250    A message body on a CONNECT request has no defined semantics. Sending a
    1251    body on a CONNECT request might cause existing implementations to reject
    1252    the request.
    1253 </t>
    1254 <t>
    1255    Similar to a pipelined HTTP/1.1 request, data to be tunneled from client
    1256    to server &MAY; be sent immediately after the request (before a response
    1257    is received). The usual caveats also apply:
    1258    data may be discarded if the eventual response is negative, and the
    1259    connection may be reset with no response if more than one TCP segment
    1260    is outstanding.
    1261 </t>
    1262 <t>
    1263    It may be the case that the proxy itself can only reach the requested
    1264    origin server through another proxy.  In this case, the first proxy
    1265    &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel
    1266    to the authority.  A proxy &MUST-NOT; respond with any 2xx status code
    1267    unless it has either a direct or tunnel connection established to the
    1268    authority.
    1269 </t>
    1270 <t>
    1271    If at any point either one of the peers gets disconnected, any
    1272    outstanding data that came from that peer will be passed to the other
    1273    one, and after that also the other connection will be terminated by
    1274    the proxy. If there is outstanding data to that peer undelivered,
    1275    that data will be discarded.
    1276 </t>
    1277 <t>
    1278    An origin server which receives a CONNECT request for itself &MAY;
    1279    respond with a 2xx status code to indicate that a connection is
    1280    established.  However, most origin servers do not implement CONNECT.
    1281 </t>
    1282 </section>
    1283 </section>
    1284 
    1285 
    1286741<section title="Status Code Definitions" anchor="status.codes">
    1287 <t>
    1288    The first digit of the status-code defines the class of response. The
    1289    last two digits do not have any categorization role. There are 5
    1290    values for the first digit:
    1291   <list style="symbols">
    1292     <t>
    1293       1xx: Informational - Request received, continuing process
    1294     </t>
    1295     <t>
    1296       2xx: Success - The action was successfully received,
    1297         understood, and accepted
    1298     </t>
    1299     <t>
    1300       3xx: Redirection - Further action needs to be taken in order to
    1301         complete the request
    1302     </t>
    1303     <t>
    1304       4xx: Client Error - The request contains bad syntax or cannot
    1305         be fulfilled
    1306     </t>
    1307     <t>
    1308       5xx: Server Error - The server failed to fulfill an apparently
    1309         valid request
    1310     </t>
    1311   </list>
    1312 </t>
    1313742<t>
    1314743   Each status-code is described below, including any metadata required
    … …  
    21471576</section>
    21481577
     1578</section>
     1579
     1580<section title="Representation" anchor="representation">
     1581<t>
     1582   Request and Response messages &MAY; transfer a representation if not otherwise
     1583   restricted by the request method or response status code. A representation
     1584   consists of metadata (representation header fields) and data (representation
     1585   body).  When a complete or partial representation is enclosed in an HTTP message,
     1586   it is referred to as the payload of the message. HTTP representations
     1587   are defined in &payload;.
     1588</t>
     1589<t>
     1590   A representation body is only present in a message when a message body is
     1591   present, as described in &message-body;. The representation body is obtained
     1592   from the message body by decoding any Transfer-Encoding that might
     1593   have been applied to ensure safe and proper transfer of the message.
     1594</t>
     1595
     1596<section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">
     1597<t>
     1598   It is sometimes necessary to determine an identifier for the resource
     1599   associated with a representation.
     1600</t>
     1601<t>
     1602   An HTTP request representation, when present, is always associated with an
     1603   anonymous (i.e., unidentified) resource.
     1604</t>
     1605<t>
     1606   In the common case, an HTTP response is a representation of the target
     1607   resource (see &effective-request-uri;). However, this is not always the
     1608   case. To determine the URI of the resource a response is associated with,
     1609   the following rules are used (with the first applicable one being selected):
     1610</t>
     1611<t><list style="numbers">
     1612   <t>If the response status code is 200 or 203 and the request method was GET,
     1613   the response payload is a representation of the target resource.</t>
     1614   <t>If the response status code is 204, 206, or 304 and the request method was GET
     1615   or HEAD, the response payload is a partial representation of the target
     1616   resource.</t>
     1617   <t>If the response has a Content-Location header field, and that URI is the same
     1618   as the effective request URI, the response payload is a representation of the
     1619   target resource.</t>
     1620   <t>If the response has a Content-Location header field, and that URI is not the
     1621   same as the effective request URI, then the response asserts that its
     1622   payload is a representation of the resource identified by the
     1623   Content-Location URI. However, such an assertion cannot be trusted unless
     1624   it can be verified by other means (not defined by HTTP).</t>
     1625   <t>Otherwise, the response is a representation of an anonymous (i.e.,
     1626   unidentified) resource.</t>
     1627</list></t>
     1628<t>
     1629  <cref anchor="TODO-req-uri">
     1630   The comparison function is going to have to be defined somewhere,
     1631   because we already need to compare URIs for things like cache invalidation.</cref>
     1632</t>
     1633</section>
     1634
     1635</section>
     1636
     1637
     1638<section title="Method Definitions" anchor="method.definitions">
     1639<t>
     1640   The set of common request methods for HTTP/1.1 is defined below. Although
     1641   this set can be expanded, additional methods cannot be assumed to
     1642   share the same semantics for separately extended clients and servers.
     1643</t>
     1644
     1645<section title="Safe and Idempotent Methods" anchor="safe.and.idempotent">
     1646
     1647<section title="Safe Methods" anchor="safe.methods">
     1648<iref item="Safe Methods" primary="true"/>
     1649<t>
     1650   Implementors need to be aware that the software represents the user in
     1651   their interactions over the Internet, and need to allow
     1652   the user to be aware of any actions they take which might have an
     1653   unexpected significance to themselves or others.
     1654</t>
     1655<t>
     1656   In particular, the convention has been established that the GET, HEAD,
     1657   OPTIONS, and TRACE request methods &SHOULD-NOT; have the significance
     1658   of taking an action other than retrieval. These request methods ought
     1659   to be considered "<x:dfn anchor="safe">safe</x:dfn>".
     1660   This allows user agents to represent other methods, such as POST, PUT
     1661   and DELETE, in a special way, so that the user is made aware of the
     1662   fact that a possibly unsafe action is being requested.
     1663</t>
     1664<t>
     1665   Naturally, it is not possible to ensure that the server does not
     1666   generate side-effects as a result of performing a GET request; in
     1667   fact, some dynamic resources consider that a feature. The important
     1668   distinction here is that the user did not request the side-effects,
     1669   so therefore cannot be held accountable for them.
     1670</t>
     1671</section>
     1672
     1673<section title="Idempotent Methods" anchor="idempotent.methods">
     1674<iref item="Idempotent Methods" primary="true"/>
     1675<t>
     1676   Request methods can also have the property of "idempotence" in that,
     1677   aside from error or expiration issues, the intended effect of multiple
     1678   identical requests is the same as for a single request.
     1679   PUT, DELETE, and all safe request methods are idempotent.
     1680   It is important to note that idempotence refers only to changes
     1681   requested by the client: a server is free to change its state due
     1682   to multiple requests for the purpose of tracking those requests,
     1683   versioning of results, etc.
     1684</t>
     1685</section>
     1686</section>
     1687
     1688<section title="OPTIONS" anchor="OPTIONS">
     1689  <rdf:Description>
     1690    <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
     1691  </rdf:Description>
     1692  <iref primary="true" item="OPTIONS method" x:for-anchor=""/>
     1693  <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/>
     1694<t>
     1695   The OPTIONS method requests information about the
     1696   communication options available on the request/response chain
     1697   identified by the effective request URI. This method allows a client to
     1698   determine the options and/or requirements associated with a resource,
     1699   or the capabilities of a server, without implying a resource action
     1700   or initiating a resource retrieval.
     1701</t>
     1702<t>
     1703   Responses to the OPTIONS method are not cacheable.
     1704</t>
     1705<t>
     1706   If the OPTIONS request includes a message body (as indicated by the
     1707   presence of Content-Length or Transfer-Encoding), then the media type
     1708   &MUST; be indicated by a Content-Type field. Although this
     1709   specification does not define any use for such a body, future
     1710   extensions to HTTP might use the OPTIONS body to make more detailed
     1711   queries on the server.
     1712</t>
     1713<t>
     1714   If the request-target (&request-target;) is an asterisk ("*"),
     1715   the OPTIONS request is
     1716   intended to apply to the server in general rather than to a specific
     1717   resource. Since a server's communication options typically depend on
     1718   the resource, the "*" request is only useful as a "ping" or "no-op"
     1719   type of method; it does nothing beyond allowing the client to test
     1720   the capabilities of the server. For example, this can be used to test
     1721   a proxy for HTTP/1.1 conformance (or lack thereof).
     1722</t>
     1723<t>
     1724   If the request-target is not an asterisk, the OPTIONS request applies
     1725   only to the options that are available when communicating with that
     1726   resource.
     1727</t>
     1728<t>
     1729   A 200 response &SHOULD; include any header fields that indicate
     1730   optional features implemented by the server and applicable to that
     1731   resource (e.g., Allow), possibly including extensions not defined by
     1732   this specification. The response body, if any, &SHOULD; also include
     1733   information about the communication options. The format for such a
     1734   body is not defined by this specification, but might be defined by
     1735   future extensions to HTTP. Content negotiation &MAY; be used to select
     1736   the appropriate response format. If no response body is included, the
     1737   response &MUST; include a Content-Length field with a field-value of
     1738   "0".
     1739</t>
     1740<t>
     1741   The Max-Forwards header field &MAY; be used to target a
     1742   specific proxy in the request chain (see <xref target="header.max-forwards"/>).
     1743   If no Max-Forwards field is present in the request, then the forwarded
     1744   request &MUST-NOT; include a Max-Forwards field.
     1745</t>
     1746</section>
     1747
     1748<section title="GET" anchor="GET">
     1749  <rdf:Description>
     1750    <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
     1751  </rdf:Description>
     1752  <iref primary="true" item="GET method" x:for-anchor=""/>
     1753  <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/>
     1754<t>
     1755   The GET method requests transfer of a current representation of
     1756   the target resource.
     1757</t>
     1758<t>   
     1759   If the target resource is a data-producing process, it is the
     1760   produced data which shall be returned as the representation in the response and not
     1761   the source text of the process, unless that text happens to be the output of
     1762   the process.
     1763</t>
     1764<t>
     1765   The semantics of the GET method change to a "conditional GET" if the
     1766   request message includes an If-Modified-Since, If-Unmodified-Since,
     1767   If-Match, If-None-Match, or If-Range header field. A conditional GET
     1768   requests that the representation be transferred only under the
     1769   circumstances described by the conditional header field(s). The
     1770   conditional GET request is intended to reduce unnecessary network
     1771   usage by allowing cached representations to be refreshed without requiring
     1772   multiple requests or transferring data already held by the client.
     1773</t>
     1774<t>
     1775   The semantics of the GET method change to a "partial GET" if the
     1776   request message includes a Range header field. A partial GET requests
     1777   that only part of the representation be transferred, as described in &header-range;.
     1778   The partial GET request is intended to reduce unnecessary
     1779   network usage by allowing partially-retrieved representations to be
     1780   completed without transferring data already held by the client.
     1781</t>
     1782<t>
     1783   Bodies on GET requests have no defined semantics. Note that sending a body
     1784   on a GET request might cause some existing implementations to reject the
     1785   request.
     1786</t>
     1787<t>
     1788   The response to a GET request is cacheable and &MAY; be used to satisfy
     1789   subsequent GET and HEAD requests (see &caching;).
     1790</t>
     1791<t>
     1792   See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms.
     1793</t>
     1794</section>
     1795
     1796<section title="HEAD" anchor="HEAD">
     1797  <rdf:Description>
     1798    <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
     1799  </rdf:Description>
     1800  <iref primary="true" item="HEAD method" x:for-anchor=""/>
     1801  <iref primary="true" item="Methods" subitem="HEAD" x:for-anchor=""/>
     1802<t>
     1803   The HEAD method is identical to GET except that the server &MUST-NOT;
     1804   return a message body in the response. The metadata contained
     1805   in the HTTP header fields in response to a HEAD request &SHOULD; be identical
     1806   to the information sent in response to a GET request. This method can
     1807   be used for obtaining metadata about the representation implied by the
     1808   request without transferring the representation body. This method is
     1809   often used for testing hypertext links for validity, accessibility,
     1810   and recent modification.
     1811</t>
     1812<t>
     1813   The response to a HEAD request is cacheable and &MAY; be used to satisfy
     1814   a subsequent HEAD request. It also has potential side effects on
     1815   previously stored responses to GET; see &p6-head;.
     1816</t>
     1817<t>
     1818   Bodies on HEAD requests have no defined semantics. Note that sending a body
     1819   on a HEAD request might cause some existing implementations to reject the
     1820   request.
     1821</t>
     1822</section>
     1823
     1824<section title="POST" anchor="POST">
     1825  <iref primary="true" item="POST method" x:for-anchor=""/>
     1826  <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/>
     1827<t>
     1828   The POST method requests that the origin server accept the
     1829   representation enclosed in the request as data to be processed by the
     1830   target resource. POST is designed to allow a uniform method to cover the
     1831   following functions:
     1832  <list style="symbols">
     1833    <t>
     1834      Annotation of existing resources;
     1835    </t>
     1836    <t>
     1837        Posting a message to a bulletin board, newsgroup, mailing list,
     1838        or similar group of articles;
     1839    </t>
     1840    <t>
     1841        Providing a block of data, such as the result of submitting a
     1842        form, to a data-handling process;
     1843    </t>
     1844    <t>
     1845        Extending a database through an append operation.
     1846    </t>
     1847  </list>
     1848</t>
     1849<t>
     1850   The actual function performed by the POST method is determined by the
     1851   server and is usually dependent on the effective request URI.
     1852</t>
     1853<t>
     1854   The action performed by the POST method might not result in a
     1855   resource that can be identified by a URI. In this case, either 200
     1856   (OK) or 204 (No Content) is the appropriate response status code,
     1857   depending on whether or not the response includes a representation that
     1858   describes the result.
     1859</t>
     1860<t>
     1861   If a resource has been created on the origin server, the response
     1862   &SHOULD; be 201 (Created) and contain a representation which describes the
     1863   status of the request and refers to the new resource, and a Location
     1864   header field (see <xref target="header.location"/>).
     1865</t>
     1866<t>
     1867   Responses to POST requests are only cacheable when they
     1868   include explicit freshness information (see &p6-explicit;). A
     1869   cached POST response with a Content-Location header field
     1870   (see &header-content-location;) whose value is the effective
     1871   Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.
     1872</t>
     1873<t>
     1874   Note that POST caching is not widely implemented.
     1875   However, the 303 (See Other) response can be used to direct the
     1876   user agent to retrieve a cacheable representation of the resource.
     1877</t>
     1878</section>
     1879
     1880<section title="PUT" anchor="PUT">
     1881  <iref primary="true" item="PUT method" x:for-anchor=""/>
     1882  <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/>
     1883<t>
     1884   The PUT method requests that the state of the target resource
     1885   be created or replaced with the state defined by the representation
     1886   enclosed in the request message payload.  A successful PUT of a given
     1887   representation would suggest that a subsequent GET on that same target
     1888   resource will result in an equivalent representation being returned in
     1889   a 200 (OK) response.  However, there is no guarantee that such a state
     1890   change will be observable, since the target resource might be acted
     1891   upon by other user agents in parallel, or might be subject to dynamic
     1892   processing by the origin server, before any subsequent GET is received.
     1893   A successful response only implies that the user agent's intent was
     1894   achieved at the time of its processing by the origin server.
     1895</t>
     1896<t>   
     1897   If the target resource does not have a current representation and
     1898   the PUT successfully creates one, then the origin server &MUST; inform
     1899   the user agent by sending a 201 (Created) response.  If the target
     1900   resource does have a current representation and that representation is
     1901   successfully modified in accordance with the state of the enclosed
     1902   representation, then either a 200 (OK) or 204 (No Content) response
     1903   &SHOULD; be sent to indicate successful completion of the request.
     1904</t>
     1905<t>
     1906   Unrecognized header fields &SHOULD; be ignored (i.e., not saved
     1907   as part of the resource state).
     1908</t>
     1909<t>
     1910   An origin server &SHOULD; verify that the PUT representation is
     1911   consistent with any constraints which the server has for the target
     1912   resource that cannot or will not be changed by the PUT.  This is
     1913   particularly important when the origin server uses internal
     1914   configuration information related to the URI in order to set the
     1915   values for representation metadata on GET responses.  When a PUT
     1916   representation is inconsistent with the target resource, the origin
     1917   server &SHOULD; either make them consistent, by transforming the
     1918   representation or changing the resource configuration, or respond
     1919   with an appropriate error message containing sufficient information
     1920   to explain why the representation is unsuitable.  The 409 (Conflict)
     1921   or 415 (Unsupported Media Type) status codes are suggested, with the
     1922   latter being specific to constraints on Content-Type values.
     1923</t>
     1924<t>
     1925   For example, if the target resource is configured to always have a
     1926   Content-Type of "text/html" and the representation being PUT has a
     1927   Content-Type of "image/jpeg", then the origin server &SHOULD; do one of:
     1928   (a) reconfigure the target resource to reflect the new media type;
     1929   (b) transform the PUT representation to a format consistent with that
     1930   of the resource before saving it as the new resource state; or,
     1931   (c) reject the request with a 415 response indicating that the target
     1932   resource is limited to "text/html", perhaps including a link to a
     1933   different resource that would be a suitable target for the new
     1934   representation.
     1935</t>
     1936<t>
     1937   HTTP does not define exactly how a PUT method affects the state
     1938   of an origin server beyond what can be expressed by the intent of
     1939   the user agent request and the semantics of the origin server response.
     1940   It does not define what a resource might be, in any sense of that
     1941   word, beyond the interface provided via HTTP.  It does not define
     1942   how resource state is "stored", nor how such storage might change
     1943   as a result of a change in resource state, nor how the origin server
     1944   translates resource state into representations.  Generally speaking,
     1945   all implementation details behind the resource interface are
     1946   intentionally hidden by the server.
     1947</t>
     1948<t>
     1949   The fundamental difference between the POST and PUT methods is
     1950   highlighted by the different intent for the target resource.
     1951   The target resource in a POST request is intended to handle the
     1952   enclosed representation as a data-accepting process, such as for
     1953   a gateway to some other protocol or a document that accepts annotations.
     1954   In contrast, the target resource in a PUT request is intended to
     1955   take the enclosed representation as a new or replacement value.
     1956   Hence, the intent of PUT is idempotent and visible to intermediaries,
     1957   even though the exact effect is only known by the origin server.
     1958</t>
     1959<t>
     1960   Proper interpretation of a PUT request presumes that the user agent
     1961   knows what target resource is desired.  A service that is intended
     1962   to select a proper URI on behalf of the client, after receiving
     1963   a state-changing request, &SHOULD; be implemented using the POST
     1964   method rather than PUT.  If the origin server will not make the
     1965   requested PUT state change to the target resource and instead
     1966   wishes to have it applied to a different resource, such as when the
     1967   resource has been moved to a different URI, then the origin server
     1968   &MUST; send a 301 (Moved Permanently) response; the user agent &MAY;
     1969   then make its own decision regarding whether or not to redirect the
     1970   request.
     1971</t>
     1972<t>
     1973   A PUT request applied to the target resource &MAY; have side-effects
     1974   on other resources.  For example, an article might have a URI for
     1975   identifying "the current version" (a resource) which is separate
     1976   from the URIs identifying each particular version (different
     1977   resources that at one point shared the same state as the current version
     1978   resource).  A successful PUT request on "the current version" URI might
     1979   therefore create a new version resource in addition to changing the
     1980   state of the target resource, and might also cause links to be added
     1981   between the related resources.
     1982</t>
     1983<t>
     1984   An origin server &SHOULD; reject any PUT request that contains a
     1985   Content-Range header field, since it might be misinterpreted as
     1986   partial content (or might be partial content that is being mistakenly
     1987   PUT as a full representation).  Partial content updates are
     1988   possible by targeting a separately identified resource with state
     1989   that overlaps a portion of the larger resource, or by using a
     1990   different method that has been specifically defined for partial
     1991   updates (for example, the PATCH method defined in
     1992   <xref target="RFC5789"/>).
     1993</t>
     1994<t>
     1995   Responses to the PUT method are not cacheable. If a PUT request passes
     1996   through a cache that has one or more stored responses for the effective
     1997   request URI, those stored responses will be invalidated (see
     1998   &p6-invalid;).
     1999</t>
     2000</section>
     2001
     2002<section title="DELETE" anchor="DELETE">
     2003  <iref primary="true" item="DELETE method" x:for-anchor=""/>
     2004  <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/>
     2005<t>
     2006   The DELETE method requests that the origin server delete the target
     2007   resource. This method &MAY; be overridden by
     2008   human intervention (or other means) on the origin server. The client cannot
     2009   be guaranteed that the operation has been carried out, even if the
     2010   status code returned from the origin server indicates that the action
     2011   has been completed successfully. However, the server &SHOULD-NOT;
     2012   indicate success unless, at the time the response is given, it
     2013   intends to delete the resource or move it to an inaccessible
     2014   location.
     2015</t>
     2016<t>
     2017   A successful response &SHOULD; be 200 (OK) if the response includes an
     2018   representation describing the status, 202 (Accepted) if the action has not
     2019   yet been enacted, or 204 (No Content) if the action has been enacted
     2020   but the response does not include a representation.
     2021</t>
     2022<t>
     2023   Bodies on DELETE requests have no defined semantics. Note that sending a body
     2024   on a DELETE request might cause some existing implementations to reject the
     2025   request.
     2026</t>
     2027<t>
     2028   Responses to the DELETE method are not cacheable. If a DELETE request
     2029   passes through a cache that has one or more stored responses for the
     2030   effective request URI, those stored responses will be invalidated (see
     2031   &p6-invalid;).
     2032</t>
     2033</section>
     2034
     2035<section title="TRACE" anchor="TRACE">
     2036  <rdf:Description>
     2037    <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>
     2038  </rdf:Description>
     2039  <iref primary="true" item="TRACE method" x:for-anchor=""/>
     2040  <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/>
     2041<t>
     2042   The TRACE method requests a remote, application-layer loop-back
     2043   of the request message. The final recipient of the request
     2044   &SHOULD; reflect the message received back to the client as the
     2045   message body of a 200 (OK) response. The final recipient is either the
     2046   origin server or the first proxy to receive a Max-Forwards
     2047   value of zero (0) in the request (see <xref target="header.max-forwards"/>).
     2048   A TRACE request &MUST-NOT; include a message body.
     2049</t>
     2050<t>
     2051   TRACE allows the client to see what is being received at the other
     2052   end of the request chain and use that data for testing or diagnostic
     2053   information. The value of the Via header field (&header-via;) is of
     2054   particular interest, since it acts as a trace of the request chain.
     2055   Use of the Max-Forwards header field allows the client to limit the
     2056   length of the request chain, which is useful for testing a chain of
     2057   proxies forwarding messages in an infinite loop.
     2058</t>
     2059<t>
     2060   If the request is valid, the response &SHOULD; have a Content-Type of
     2061   "message/http" (see &media-type-message-http;) and contain a message body
     2062   that encloses a copy of the entire request message.
     2063   Responses to the TRACE method are not cacheable.
     2064</t>
     2065</section>
     2066
     2067<section title="CONNECT" anchor="CONNECT">
     2068  <iref primary="true" item="CONNECT method" x:for-anchor=""/>
     2069  <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/>
     2070<t>
     2071   The CONNECT method requests that the proxy establish a tunnel
     2072   to the request-target and, if successful, thereafter restrict its behavior
     2073   to blind forwarding of packets until the connection is closed.
     2074</t>
     2075<t>
     2076   When using CONNECT, the request-target &MUST; use the authority form
     2077   (&request-target;); i.e., the request-target consists of only the
     2078   host name and port number of the tunnel destination, separated by a colon.
     2079   For example,
     2080</t>
     2081<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2082CONNECT server.example.com:80 HTTP/1.1
     2083Host: server.example.com:80
     2084
     2085</artwork></figure>
     2086<t>
     2087   Any successful (2xx) response to a CONNECT request indicates that the
     2088   proxy has established a connection to the requested host and port,
     2089   and has switched to tunneling the current connection to that server
     2090   connection.
     2091   The tunneled data from the server begins immediately after the blank line
     2092   that concludes the successful response's header block.
     2093   A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length
     2094   header fields in a successful response.
     2095   A client &MUST; ignore any Content-Length or Transfer-Encoding header
     2096   fields received in a successful response.
     2097</t>
     2098<t>
     2099   Any response other than a successful response indicates that the tunnel
     2100   has not yet been formed and that the connection remains governed by HTTP.
     2101</t>
     2102<t>
     2103   Proxy authentication might be used to establish the
     2104   authority to create a tunnel:
     2105</t>
     2106<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2107CONNECT server.example.com:80 HTTP/1.1
     2108Host: server.example.com:80
     2109Proxy-Authorization: basic aGVsbG86d29ybGQ=
     2110
     2111</artwork></figure>
     2112<t>
     2113   A message body on a CONNECT request has no defined semantics. Sending a
     2114   body on a CONNECT request might cause existing implementations to reject
     2115   the request.
     2116</t>
     2117<t>
     2118   Similar to a pipelined HTTP/1.1 request, data to be tunneled from client
     2119   to server &MAY; be sent immediately after the request (before a response
     2120   is received). The usual caveats also apply:
     2121   data may be discarded if the eventual response is negative, and the
     2122   connection may be reset with no response if more than one TCP segment
     2123   is outstanding.
     2124</t>
     2125<t>
     2126   It may be the case that the proxy itself can only reach the requested
     2127   origin server through another proxy.  In this case, the first proxy
     2128   &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel
     2129   to the authority.  A proxy &MUST-NOT; respond with any 2xx status code
     2130   unless it has either a direct or tunnel connection established to the
     2131   authority.
     2132</t>
     2133<t>
     2134   If at any point either one of the peers gets disconnected, any
     2135   outstanding data that came from that peer will be passed to the other
     2136   one, and after that also the other connection will be terminated by
     2137   the proxy. If there is outstanding data to that peer undelivered,
     2138   that data will be discarded.
     2139</t>
     2140<t>
     2141   An origin server which receives a CONNECT request for itself &MAY;
     2142   respond with a 2xx status code to indicate that a connection is
     2143   established.  However, most origin servers do not implement CONNECT.
     2144</t>
     2145</section>
     2146</section>
     2147
    21492148<section title="Common Protocol Parameters" anchor="common.protocol.parameters">
    21502149<section title="Date/Time Formats" anchor="http.date">
    … …  
    36853684</t>
    36863685<t>
    3687   Clarify definition of POST.
    3688   (<xref target="POST"/>)
    3689 </t>
    3690 <t>
    3691   Remove requirement to handle all Content-* header fields; ban use of
    3692   Content-Range with PUT.
    3693   (<xref target="PUT"/>)
    3694 </t>
    3695 <t>
    3696   Take over definition of CONNECT method from <xref target="RFC2817"/>.
    3697   (<xref target="CONNECT"/>)
    3698 </t>
    3699 <t>
    37003686  Broadened the definition of 203 (Non-Authoritative Information) to include
    37013687  cases of payload transformations as well.
    … …  
    37283714  <xref target="RFC2817"/>).
    37293715  (<xref target="status.426"/>)
     3716</t>
     3717<t>
     3718  Clarify definition of POST.
     3719  (<xref target="POST"/>)
     3720</t>
     3721<t>
     3722  Remove requirement to handle all Content-* header fields; ban use of
     3723  Content-Range with PUT.
     3724  (<xref target="PUT"/>)
     3725</t>
     3726<t>
     3727  Take over definition of CONNECT method from <xref target="RFC2817"/>.
     3728  (<xref target="CONNECT"/>)
    37303729</t>
    37313730<t>
Note: See TracChangeset for help on using the changeset viewer.