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

server-allow-methods in successful responses #378

Merged
merged 2 commits into from
Feb 9, 2022

Conversation

csarven
Copy link
Member

@csarven csarven commented Feb 8, 2022

This PR is a continuation of #353 with the difference being that the Allow header is included in successful responses.

Merging this PR closes #353 - There was no point in bringing that PR up to speed and changing it to modify ED/protocol.html.

<p><span about="" id="server-allow-methods" rel="spec:requirement" resource="#server-allow-methods"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> indicate their support for HTTP Methods by responding to HTTP <code>GET</code> and <code>HEAD</code> requests for the target resource with the HTTP Method tokens in the HTTP response header <code>Allow</code>.</span></span></p>

<p><span about="" id="server-accept-headers" rel="spec:requirement" resource="#server-accept-headers"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> indicate supported media types in the HTTP <code>Accept-Patch</code> [<cite><a class="bibref" href="#bib-rfc5789">RFC5789</a></cite>], <code>Accept-Post</code> [<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>] and <code>Accept-Put</code> [<cite><a href="#accept-put">The Accept-Put Response Header</a></cite>] response headers that correspond to acceptable HTTP methods listed in <code>Allow</code> header value in response to HTTP <code>GET</code>, <code>HEAD</code> and <code>OPTIONS</code> requests.</span></span></p>
<p><span about="" id="server-accept-headers" rel="spec:requirement" resource="#server-accept-headers"><span property="spec:statement">When responding to authorized requests, <span rel="spec:requirementSubject" resource="spec:Server">servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> indicate supported media types in the HTTP <code>Accept-Patch</code> [<cite><a class="bibref" href="#bib-rfc5789">RFC5789</a></cite>], <code>Accept-Post</code> [<cite><a class="bibref" href="#bib-ldp">LDP</a></cite>] and <code>Accept-Put</code> [<cite><a href="#accept-put">The Accept-Put Response Header</a></cite>] response headers that correspond to acceptable HTTP methods listed in <code>Allow</code> header value in response to HTTP <code>GET</code>, <code>HEAD</code> and <code>OPTIONS</code> requests.</span></span></p>
Copy link
Member

@acoburn acoburn Feb 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you feel that this text is sufficiently clear that CORS preflight requests (which contain no auth headers) would be exempt from the requirement to provide these Accept-* headers?

(edit: changed Allow-* to Accept-*)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I think you mean Accept-* headers) I believe / hope so. It was intended to be exempt since no auth will take place for CORS-preflight. If this is unclear to implementers, happy to revise.

Copy link
Member

@kjetilk kjetilk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, sounds good!

ED/protocol.html Show resolved Hide resolved
@csarven csarven merged commit 9139ebc into main Feb 9, 2022
@csarven
Copy link
Member Author

csarven commented Feb 22, 2022

Reading between the lines (RFC 7231):

In general, it is assumed that the origin
server will only allow DELETE on resources for which it has a
prescribed mechanism for accomplishing the deletion.
[..]
For example, a resource that was
previously created using a PUT request, or identified via the
Location header field after a 201 (Created) response to a POST
request, might allow a corresponding DELETE request to undo those
actions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

4 participants