Http allow header on different cases

Question

I'm trying to create a valid web service but I have some issue with the header ALLOW, and his cors version in different scenario.

Suppose GET /resource/42 is valid and have header allow = 'GET,PUT'

What am I supposed to do in following cases:

1) if resource not found (401) ?

2) if resource required auth (401) ?

3) if the resource is not owned by user (403) ?

4) if the request is rejected (400) because of missing api-version header?

Now, I have exactly the same question if I replace 'GET' by OPTIONS

Maybe I'm lacking knowledge on HTTP but I cannot find full and precise documentation. Anyway, thank you for you help.

Answer 1

This is a good place to begin for documentation on response codes and method types, it is the rfc spec: https://www.rfc-editor.org/rfc/rfc7231

(The full HTTP 1.1 spec is covered by rfc 7230-7237)

1. resource not found - generally best returned as 404, but you can return 410 if you know it's intentionally gone.

2. resource required auth - generally 403, (but authorization is a bigger subject)

3. resource is not owned by user - resource ownership is not covered by the spec - your application may want to serve a resource back that is owned by someone else. The response just describes the status. If you are allowing the resource to be served you can send a regular 200 based response. If you are explicitly only allowing resources after identifying ownership, and you find the client does not identify as the owner, you could send a 403 response, or if you also want to hide the knowledge that the resource even exists, you could send 404, it's more dependent on your specific needs.

4. request is rejected because of missing api-version header - yes 400 would be suitable here. You can include a message in the response to explain why it was perceived as a bad request.

For OPTIONS requests, there are a number of other posts which talk about the response code just being relevant to the specific request, e.g.: https://stackoverflow.com/a/14703357/3417917 A 200 response is fine to use for conveying the options available for a resource, but you can send a general 400 request if you want to convey that the request was bad.