5

I have a RESTful web service which requires an end-user license agreement (EULA) to be accepted before it can be used.

Which HTTP status code would be most appropriate for the web service to return if the EULA has not (yet) been accepted?

Currently I see the following possibilities (my current favorite in bold):

  • 403 Forbidden
  • 412 Precondition Failed
  • 417 Expectation Failed
  • 423 Locked
  • 428 Precondition Required#
  • 451 Unavailable For Legal Reasons
Alexander Tobias Bockstaller
  • 4,657
  • 4
  • 36
  • 58
  • So, just pick any. What's your question? :) For picking the "most appropriate" status code you can list all conditions for which you can send them, and cross any of your list whose requirements don't match your scenario. – CodeCaster Jan 11 '16 at 11:46
  • I see there's a few close votes. Apparently this is considered an opinion-driven question which surprises me - is it really just my personal taste? After all HTTP status codes are standardized, so would it be ok if I chose e.g. 404 to signal the EULA issue, even if everybody seeing that status code would immediately think the requested resource is not there? – Alexander Tobias Bockstaller Jan 11 '16 at 11:55
  • 1
    It's not that the question is opinion-based, but that as currently stated it attracts opinion-based answers rather than answers based on facts. This is inherent to questions about _"Which HTTP status code to use for arbitrary situation X"_, because people don't bother to read the RFCs. **You** should be able to do that just fine as I indicated in my previous comment. List the candidate codes and eliminate any whose conditions your situation does not match. – CodeCaster Jan 11 '16 at 12:23
  • I like 451 too, thanks, it's my new favorite http status code :) However, I think 403 is more appropriate. According to RFC 7725 `The use of the 451 status code implies neither the existence nor nonexistence of the resource named in the request. That is to say, it is possible that if the legal demands were removed, a request for the resource still might not succeed.` https://tools.ietf.org/html/rfc7725 In other words, it's more like a 404 "this doesn't exist," whereas what you really want to say is "it's there, but I'm not letting you see it." – stephan.com Mar 07 '18 at 03:55

3 Answers3

5

As suggested by CodeCaster I went to w3.org and looked at the definitions of HTTP Status Codes in RFC2616. I found Status Code 403 to be most appropriate:

10.4.4 403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

Community
  • 1
  • 1
Alexander Tobias Bockstaller
  • 4,657
  • 4
  • 36
  • 58
-1

401 Unauthorized

As George Clooney would say: "What else!". You authorize people accessing your service after they agree with the EULA. They didn't do that, so they aren't authorized (to be compliant with the RFC, authenticating and retrying clients would have to include the WWW-Authenticate header, but you must somehow provide that information anyway, and this way is just as good as any other way).

On a different thought, you could just as well return 301 pointing to the agreement page. The reasoning behind that approach would be that 4xx codes signal an error condition. However, not having agreed to the EULA yet is (other than a failed authentication) not really an error condition.
It's preventing the service from being used, yes... but everything is "working fine".

Damon
  • 67,688
  • 20
  • 135
  • 185
  • 2
    This question has nothing to do with authentication. What you're talking about is authentication, which is not what 401 is for. See [403 Forbidden vs 401 Unauthorized HTTP responses](http://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses). – CodeCaster Jan 11 '16 at 12:16
  • Second "authentication" should be "authorization", of course. – CodeCaster Jan 11 '16 at 12:25
  • @CodeCaster: No, it should not be. The accepted answer in the Q that you linked entirely confirms my reasoning. The meaning of the code is that the server received an intact, valid request, but it did not receive an authentication token (hence your confusion!) which **authorizes** you to access the resource. That may be because your token is invalid or belongs to the wrong group or whatever, or simply because you didn't supply one at all. Now, this is just what is happening here. You must agree to the EULA, and receive a token that authenticates you as member of the "Accepted EULA" user group. – Damon Jan 11 '16 at 12:28
  • ... which, in turn, authorizes you (if you provide the token). So, authorization is the correct word. `403 Forbidden` is wrong. It's not forbidden to access the resource (not in general, nor to you in particular), it just _isn't clear_ that you are someone who may access it. You didn't pass the required check, that's all. – Damon Jan 11 '16 at 12:29
  • 1
    Well I _guess_ that OP's API users do a one-time POST to `AcceptEula` to flag their account as "can use the API", not that OP introduced a new authentication scheme based on EULAs and tokens. Hence this question has to do with **authorization**, which is not what 401 is for. A 401 response _must_ contain a `WWW-Authenticate` response header, which cannot be done unless OP invented their own schema. Nowhere am I advocating for 403, but if you'd actually [read the RFC](https://tools.ietf.org/html/rfc7231#section-6.5.3), you'd see that it would be a viable response in this case. – CodeCaster Jan 11 '16 at 12:30
  • @CodeCaster: Assuming that there _are_ permanent accounts at all (no mention of that in the question), simply flagging the account could be done. Of course, the client would _still_ have to provide a token to authentify as that user (obtained at login), and failure to do provide one that passes would give a 401. My interpretation of the question was (since there's no mention of accounts) that you need to accept an EULA prior to using the service (that is, every time, without registering an account), which would make this impossible. – Damon Jan 11 '16 at 12:39
  • Alright, if you explain it like that then you're right I guess. :) Would you mind editing that into your answer? – CodeCaster Jan 11 '16 at 12:39
-2

Messages should be self explanatory, my vote also for 412 Precondition Failed.

RKT
  • 174
  • 1
  • 4
  • 2
    But that's not how HTTP status codes work. Please read [When is it appropriate to respond with a HTTP 412 error?](http://stackoverflow.com/questions/5369480/when-is-it-appropriate-to-respond-with-a-http-412-error). 412 is to be returned for a failed conditional request. – CodeCaster Jan 11 '16 at 12:10