search

sknebel / AutoAuth

AutoAuth is a WIP extension for IndieAuth without the user being present
13 stars 0 forks source link

Unspecified "200 OK" responses acceptable? #3

Open sknebel opened 6 years ago

sknebel commented 6 years ago

The access code validation and the requests for later callbacks currently have no response specified, only that it is supposed to be a HTTP 200 (in contrast to an error code). Is this acceptable, or should specific responses be specified?

fluffy-critter commented 5 years ago

My read on it is that the response should be appropriate to what would be presented for an unauthorized access to the resource. If there’s content to be served it’s a 200, if there’s no content due to lack of access it’s 403, if there’s no content due to it being nonexistent it’s 404 or 410, and so on.

The wording could probably be clarified along those lines though (especially if I’m not reading it right).

Zegnat commented 5 years ago

I think specifying more specific responses wherever possible is a good thing. This will ensure implementers that anything else is a garbage response.

If we are talking about requests that set a callback, maybe we can take inspiration from WebSub’s subscription response, which details both the OK and failure states:

If the hub URL supports WebSub and is able to handle the subscription or unsubscription request, it MUST respond to a subscription request with an HTTP [RFC7231] 202 "Accepted" response to indicate that the request was received and will now be verified (Section 4.3 ) and validated (Section 4.2 ) by the hub. The hub SHOULD perform the verification and validation of intent as soon as possible.

If a hub finds any errors in the subscription request, an appropriate HTTP [RFC7231] error response code (4xx or 5xx) MUST be returned. In the event of an error, hubs SHOULD return a description of the error in the response body as plain text, used to assist the client developer in understanding the error. This is not meant to be shown to the end user. Hubs MAY decide to reject some callback URLs or topic URLs based on their own policies (e.g., domain authorization, topic URL port numbers). However, since verification and validation of intent are asynchronous steps that logically begin after the HTTP response has been returned, the HTTP response MUST NOT depend on the process or outcome of verification or validation.

sknebel commented 5 years ago

Ok, I clearly need to rework the wording on errors - errors should of course not use 2xx status codes, and I hadn't intended them to.

Good point on 202, that might fit some cases.