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

Allow "Accept" in response messages (#48) #382

Merged
merged 2 commits into from
Jul 1, 2020
Merged
Changes from all commits
Commits
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
25 changes: 20 additions & 5 deletions draft-ietf-httpbis-semantics-latest.xml
Original file line number Diff line number Diff line change
Expand Up @@ -6259,6 +6259,11 @@ Expect: 100-continue
a small set of desired types, as in the case of a request for an in-line
image.
</t>
<t>
When sent by a server in a response, Accept provides information
about what content types are preferred in the payload of a subsequent
request to the same resource.
</t>
<sourcecode type="abnf7230"><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/>
<x:ref>Accept</x:ref> = #( <x:ref>media-range</x:ref> [ <x:ref>accept-params</x:ref> ] )

Expand Down Expand Up @@ -8665,12 +8670,21 @@ Content-Range: bytes 7000-7999/8000
<t>
The format problem might be due to the request's indicated
<x:ref>Content-Type</x:ref> or <x:ref>Content-Encoding</x:ref>, or as a
result of inspecting the data directly. If the problem was caused by an
unsupported content coding, the <x:ref>Accept-Encoding</x:ref>
response header field (<xref target="field.accept-encoding"/>) ought to be
result of inspecting the data directly.
</t>
<t>
If the problem was caused by an unsupported content coding, the
<x:ref>Accept-Encoding</x:ref> response header field
(<xref target="field.accept-encoding"/>) ought to be
used to indicate what (if any) content codings would have been accepted
in the request.
</t>
<t>
On the other hand, if the cause was an unsupported media type, the
<x:ref>Accept</x:ref> response header field (<xref target="field.accept"/>)
can be used to indicate what media types would have been accepted
in the request.
</t>
</section>

<section title="416 Range Not Satisfiable" anchor="status.416">
Expand Down Expand Up @@ -12349,8 +12363,8 @@ Content-Encoding: gzip
(<xref target="OPTIONS"/>)
</t>
<t>
Allow <x:ref>Accept-Encoding</x:ref> in response messages, as introduced by
<xref target="RFC7694"/>.
Allow <x:ref>Accept</x:ref> and <x:ref>Accept-Encoding</x:ref> in response
messages; the latter was introduced by <xref target="RFC7694"/>.
(<xref target="request.conneg"/>)
</t>
</section>
Expand Down Expand Up @@ -12580,6 +12594,7 @@ Content-Encoding: gzip

<section title="Since draft-ietf-httpbis-semantics-08" anchor="changes.since.08">
<ul x:when-empty="None yet.">
<li>In <xref target="field.accept"/> and <xref target="status.415"/>, allow "Accept" as resonse field (<eref target="https://github.com/httpwg/http-core/issues/48"/>)</li>
<li>In <xref target="field.name.registry"/>, add optional "Comments" entry (<eref target="https://github.com/httpwg/http-core/issues/273"/>)</li>
<li>In <xref target="field.values"/>, update note about field ABNF (<eref target="https://github.com/httpwg/http-core/issues/380"/>)</li>
</ul>
Expand Down