Source: https://trac.ietf.org/trac/httpbis/changeset/2561/draft-ietf-httpbis/latest
Timestamp: 2020-08-07 04:27:05
Document Index: 622427666

Matched Legal Cases: ['art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2']

Changeset 2561 for draft-ietf-httpbis/latest – Hypertext Transfer Protocol Wiki
Changeset 2561 for draft-ietf-httpbis/latest
19/01/14 02:53:35 (7 years ago)
(editorial) add section xrefs where the common method names are first used; see #531
<p id="rfc.section.2.1.p.9">The following example illustrates a typical message exchange for a GET request (<a href="p2-semantics.html#GET" title="GET">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) on the URI "http://www.example.com/hello.txt":
the client can't change the protocol it is sending in the middle of a message). If a server receives both Upgrade and an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation (<a href="p2-semantics.html#header.expect" title="Expect">Section 5.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), the server <em class="bcp14">MUST</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response.
purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
<p id="rfc.section.8.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
<p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
<li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">4.3</a>, <a href="#rfc.xref.Part2.19">5.1</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.3</a>, <a href="#rfc.xref.Part2.22">5.6</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">6.3.1</a>, <a href="#rfc.xref.Part2.26">6.3.2</a>, <a href="#rfc.xref.Part2.27">6.3.2</a>, <a href="#rfc.xref.Part2.28">6.7</a>, <a href="#rfc.xref.Part2.29">6.7</a>, <a href="#rfc.xref.Part2.30">8.4.1</a>, <a href="#rfc.xref.Part2.31">9.3</a>, <a href="#rfc.xref.Part2.32">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul>
<li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.30">8.4.1</a></li>
<li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">6.7</a></li>
<li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">6.7</a></li>
<li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.32">9.3</a></li>
<li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.31">9.3</a></li>
GET request (&GET;) on the URI "http://www.example.com/hello.txt":
Responses to the HEAD request method (&HEAD;) never include a message body
method had been GET (&GET;).
<x:ref>2xx (Successful)</x:ref> responses to a CONNECT request method
(&CONNECT;) switch to tunnel mode instead of having a message body.
URI, then the recipient <em class="bcp14">MAY</em> consider the payload to be a current representation of that resource at the time indicated by the message origination date.
For a GET or HEAD request, this is the same as the default semantics when no Content-Location is provided by the server. For
a state-changing request like PUT or POST, it implies that the server's response contains the new representation of that resource,
thereby distinguishing it from representations that might only report about the action (e.g., "It worked!"). This allows authoring
applications to update their local copies without the need for a subsequent GET request.
For a GET (<a href="#GET" id="rfc.xref.GET.2" title="GET">Section&nbsp;4.3.1</a>) or HEAD (<a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section&nbsp;4.3.2</a>) request, this is the same as the default semantics when no Content-Location is provided by the server. For a state-changing
request like PUT (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) or POST (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>), it implies that the server's response contains the new representation of that resource, thereby distinguishing it from
representations that might only report about the action (e.g., "It worked!"). This allows authoring applications to update
their local copies without the need for a subsequent GET request.
a PUT request (<a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the <a href="#resources" class="smpl">target resource</a> if the request is successfully applied, whereas a representation in the payload of a POST request (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section&nbsp;4.3.3</a>) represents information to be processed by the target resource.
payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.2" title="GET">Section&nbsp;4.3.1</a>) represents the current state of the <a href="#resources" class="smpl">target resource</a>, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.1.1.2</a>), whereas the payload of the same status code in a response to POST might represent either the processing result or the new
payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.3" title="GET">Section&nbsp;4.3.1</a>) represents the current state of the <a href="#resources" class="smpl">target resource</a>, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.1.1.2</a>), whereas the payload of the same status code in a response to POST might represent either the processing result or the new
<td class="left"><a href="#GET" id="rfc.xref.GET.3" title="GET">4.3.1</a></td>
<td class="left"><a href="#GET" id="rfc.xref.GET.4" title="GET">4.3.1</a></td>
<td class="left">Same as GET, but only transfer the status line and header section.</td>
<td class="left"><a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">4.3.2</a></td>
<td class="left"><a href="#POST" id="rfc.xref.POST.2" title="POST">4.3.3</a></td>
<td class="left"><a href="#POST" id="rfc.xref.POST.3" title="POST">4.3.3</a></td>
<td class="left"><a href="#PUT" id="rfc.xref.PUT.2" title="PUT">4.3.4</a></td>
<td class="left"><a href="#PUT" id="rfc.xref.PUT.3" title="PUT">4.3.4</a></td>
<td class="left"><a href="#GET" id="rfc.xref.GET.4" title="GET">Section&nbsp;4.3.1</a>
<td class="left"><a href="#GET" id="rfc.xref.GET.5" title="GET">Section&nbsp;4.3.1</a>
<td class="left"><a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section&nbsp;4.3.2</a>
<td class="left"><a href="#HEAD" id="rfc.xref.HEAD.3" title="HEAD">Section&nbsp;4.3.2</a>
<td class="left"><a href="#POST" id="rfc.xref.POST.3" title="POST">Section&nbsp;4.3.3</a>
<td class="left"><a href="#POST" id="rfc.xref.POST.4" title="POST">Section&nbsp;4.3.3</a>
<td class="left"><a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section&nbsp;4.3.4</a>
<td class="left"><a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section&nbsp;4.3.4</a>
<li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.xref.GET.2">3.3</a>, <a href="#rfc.xref.GET.3">4.1</a>, <a href="#rfc.iref.g.14"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.4">8.1.3</a>, <a href="#rfc.xref.GET.5">B</a></li>
<li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.xref.GET.2">3.1.4.2</a>, <a href="#rfc.xref.GET.3">3.3</a>, <a href="#rfc.xref.GET.4">4.1</a>, <a href="#rfc.iref.g.14"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.5">8.1.3</a>, <a href="#rfc.xref.GET.6">B</a></li>
<li>HEAD method&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">4.1</a>, <a href="#rfc.iref.h.1"><b>4.3.2</b></a>, <a href="#rfc.xref.HEAD.2">8.1.3</a></li>
<li>HEAD method&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">3.1.4.2</a>, <a href="#rfc.xref.HEAD.2">4.1</a>, <a href="#rfc.iref.h.1"><b>4.3.2</b></a>, <a href="#rfc.xref.HEAD.3">8.1.3</a></li>
<li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3.1.4.2</a>, <a href="#rfc.xref.PUT.2">3.3</a>, <a href="#rfc.xref.PUT.3">4.1</a>, <a href="#rfc.iref.p.3"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.4">8.1.3</a>, <a href="#rfc.xref.PUT.5">B</a></li>
<t>If the request method is GET or HEAD and the response status code is
the recipient &MAY; consider the payload to be a current representation of
that resource at the time indicated by the message origination date.
For a GET (<xref target="GET"/>) or HEAD (<xref target="HEAD"/>) request,
this is the same as the default semantics when no Content-Location is
For a state-changing request like PUT (<xref target="PUT"/>) or
POST (<xref target="POST"/>), it implies that the server's response
contains the new representation of that resource, thereby distinguishing it
from representations that might only report about the action
(e.g., "It worked!").