Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

without changing the protocol, be explicit about when non-standard content in requests … #906

Merged
merged 4 commits into from
Jul 23, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 32 additions & 11 deletions draft-ietf-httpbis-semantics-latest.xml
Original file line number Diff line number Diff line change
Expand Up @@ -4621,12 +4621,18 @@ Content-Encoding: gzip
<x:ref>Range</x:ref> header field in the request (<xref target="field.range"/>).
</t>
<t>
A client &SHOULD-NOT; generate content in a GET
request. Content received in a GET request has no defined semantics,
Although request message framing is independent of the method used,
content received in a GET request has no generally defined semantics,
cannot alter the meaning or target of the request, and might lead some
implementations to reject the request and close the connection because of
its potential as a request smuggling attack
(<xref target="request.smuggling"/>).
A client &SHOULD-NOT; generate content in a GET request unless it is
made directly to an origin server that has previously indicated,
in or out of band, that such a request has a purpose and will be adequately
supported. An origin server &SHOULD-NOT; rely on private agreements to
receive content, since participants in HTTP communication are often
unaware of intermediaries along the request chain.
</t>
<t>
The response to a GET request is cacheable; a cache &MAY; use it to satisfy
Expand Down Expand Up @@ -4676,12 +4682,18 @@ Content-Encoding: gzip
sake of efficiency.
</t>
<t>
A client &SHOULD-NOT; generate content in a HEAD
request. Content received in a HEAD request has no defined semantics,
Although request message framing is independent of the method used,
content received in a HEAD request has no generally defined semantics,
cannot alter the meaning or target of the request, and might lead some
implementations to reject the request and close the connection because of
its potential as a request smuggling attack
(<xref target="request.smuggling"/>).
A client &SHOULD-NOT; generate content in a HEAD request unless it is
made directly to an origin server that has previously indicated,
in or out of band, that such a request has a purpose and will be adequately
supported. An origin server &SHOULD-NOT; rely on private agreements to
receive content, since participants in HTTP communication are often
unaware of intermediaries along the request chain.
</t>
<t>
The response to a HEAD request is cacheable; a cache &MAY; use it to
Expand Down Expand Up @@ -4935,10 +4947,18 @@ Content-Encoding: gzip
the response message includes a representation describing the status.</li>
</ul>
<t>
A client &SHOULD-NOT; generate content in a DELETE request. Content
received in a DELETE request has no defined semantics, cannot alter the
meaning or target of the request, and might lead some implementations to
reject the request.
Although request message framing is independent of the method used,
content received in a DELETE request has no generally defined semantics,
cannot alter the meaning or target of the request, and might lead some
implementations to reject the request and close the connection because of
its potential as a request smuggling attack
(<xref target="request.smuggling"/>).
A client &SHOULD-NOT; generate content in a DELETE request unless it is
made directly to an origin server that has previously indicated,
in or out of band, that such a request has a purpose and will be adequately
supported. An origin server &SHOULD-NOT; rely on private agreements to
receive content, since participants in HTTP communication are often
unaware of intermediaries along the request chain.
</t>
<t>
Responses to the DELETE method are not cacheable. If a successful DELETE
Expand Down Expand Up @@ -5032,9 +5052,9 @@ Proxy-Authorization: basic aGVsbG86d29ybGQ=
fields received in a successful response to CONNECT.
</t>
<t>
A CONNECT request message does not have content. The interpretation of and
allowability of data sent after the header section of the CONNECT
request message is specific to the version of HTTP in use.
A CONNECT request message does not have content. The interpretation of
data sent after the header section of the CONNECT request message is
specific to the version of HTTP in use.
</t>
<t>
Responses to the CONNECT method are not cacheable.
Expand Down Expand Up @@ -13683,6 +13703,7 @@ Content-Type: text/plain
<li>In <xref target="field.via"/>, don't specify TCP (<eref target="https://github.com/httpwg/http-core/issues/865"/>)</li>
<li>In <xref target="content"/>, explain the "Content-" prefix (<eref target="https://github.com/httpwg/http-core/issues/878"/>)</li>
<li>In <xref target="routing.reject"/>, check all target URIs for scheme semantic mismatches (<eref target="https://github.com/httpwg/http-core/issues/896"/>)</li>
<li>In <xref target="GET"/>, <xref target="HEAD"/>, and <xref target="DELETE"/>, clarify (again) that sending content in a request for a method that does not define such content will not interoperate without prior agreement, even if it is parsed correctly, and cannot be relied upon by an origin server unless they control the entire request chain (<eref target="https://github.com/httpwg/http-core/issues/904"/>)</li>
</ul>
</section>
</section>
Expand Down