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.

Sign up for GitHub

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

Jump to bottom

Potentially allow Range handling on methods other than GET (fixes #581) #601

Merged
merged 4 commits into from Dec 11, 2020
Merged

Potentially allow Range handling on methods other than GET (fixes #581) #601

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
86d5eae
Potentially allow Range handling on methods other than GET (fixes #581)
reschke Dec 10, 2020
a7458f2
Update draft-ietf-httpbis-semantics-latest.xml
reschke Dec 11, 2020
2cb0135
Update draft-ietf-httpbis-semantics-latest.xml
reschke Dec 11, 2020
a5836f6
Merge branch 'master' into reschke-581
reschke Dec 11, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
14 changes: 12 additions & 2 deletions draft-ietf-httpbis-semantics-latest.xml
View file
Open in desktop
Expand Up @@ -7631,8 +7631,13 @@ bytes=500-700,601-999
A server &MAY; ignore the Range header field. However, origin servers and
intermediate caches ought to support byte ranges when possible, since they
support efficient recovery from partially failed transfers and partial
retrieval of large representations. A server &MUST; ignore a Range header
field received with a request method other than GET.
retrieval of large representations.
</t>
<t>
A server &MUST; ignore a Range header field received with a request method
which is unrecognized or for which range handling is not defined. For this
specification, <x:ref>GET</x:ref> is the only method for which range handling
is defined.
</t>
<t>
An origin server &MUST; ignore a Range header field that contains a range
Expand Down Expand Up @@ -13121,6 +13126,10 @@ Content-Type: text/plain
one range. Moving the extension grammar into range specifiers also allows
protocol specific to byte ranges to be specified separately.
</t>
<t>
It is now possible to define Range handling on extension methods.
(<xref target="field.range"/>)
</t>
</section>

<section title="Changes from RFC 7235" anchor="changes.from.rfc.7235">
Expand Down Expand Up @@ -13420,6 +13429,7 @@ Content-Type: text/plain
<li>In <xref target="overview.of.status.codes"/>, clarify that "no reason phrase" is fine as well (<eref target="https://github.com/httpwg/http-core/issues/571"/>)</li>
<li>In <xref target="status.203"/>, remove an obsolete reference to the Warning response header field (<eref target="https://github.com/httpwg/http-core/issues/573"/>)</li>
<li>In <xref target="status.408"/>, rephrase prose about connection re-use (<eref target="https://github.com/httpwg/http-core/issues/579"/>)</li>
<li>In <xref target="field.range"/>, potentially allow Range handling on methods other than GET (<eref target="https://github.com/httpwg/http-core/issues/581"/>)</li>
<li>In <xref target="status.code.registration"/>, remove redundant text about status code 418 (<eref target="https://github.com/httpwg/http-core/issues/583"/>)</li>
<li>In <xref target="confidentiality.of.credentials"/>, rewrite requirement to refer to "secured connection" (<eref target="https://github.com/httpwg/http-core/issues/587"/>)</li>
<li>Make reference to <xref target="RFC8446"/> normative (<eref target="https://github.com/httpwg/http-core/issues/589"/>)</li>
Expand Down