HTTP Status Code for Captcha

Question

Sometimes (when the resource is requested too often) I'm intercepting the presentation of a (HTML) resource with a captcha. The interception doesn't produce any redirection. It happens all at the same URI.

I'm wondering now which HTTP status code would fit most for these requirements:

• it should fit semantically.

• Google should understand that this interception is a temporary condition which should not affect the existing resource in its index.

• A web browser will display the response body with the captcha.

These are my candidates which I identified so far:

409 Conflict

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict.

This sounds perfect. The conflict state comes from those clients requesting the resource too often. The response also includes enough information to identify the source of conflict plus resolve it.

503 Service Unavailable

The server is currently unable to handle the request due to a temporary overloading […] of the server. The implication is that this is a temporary condition […]. If known, the length of the delay MAY be indicated in a Retry-After header.

This sounds moderately appropriate. I might even know the length of delay and provide such header. But I'm missing here the point that the user can resolve the problem. Furthermore the scope is too broad (overloaded server vs. overloaded resource).

Solution 1

You may want to consider status code 429, defined in https://www.rfc-editor.org/rfc/rfc6585#section-4.

Solution 2

For me 422 is somewhat accurate for this case:

response status code indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions.

Comments

[John]

I was thinking that 401 would be an appropriate response. Captcha is a form of authentication with the intent of authenticating the humanity of the controller of the user-agent. I'm looking into what to supply in in the WWW-Authenticate header, but I'm going to start with WWW-Authenticate: X-Captcha

[Julian Reschke]

Well, 401 implies presence of a defined authentication scheme. Don't make up a scheme just to be able to use 401.

[John]

The RFC requires that a challenge be presented, but it doesn't require that all user-agents understand the challenge. The example is a challenge for a scheme that is not present in the standards, so that leads me to believe that if the application is able to make use of the scheme, it is reasonable to introduce it. When I read the spec for 429, it seems the client is supposed to stop making requests. That's not the behavior desired: we want the client to resubmit the request after authenticating. Youtube uses 402 when there are too many requests, but that status is now reserved for future use.

[Константин Ван]

@JulianReschke Why not making a custom auth-scheme up? RFC 7235 says “okay” with that.

[Julian Reschke]

@КонстантинВан could you be more specific? Yes, you can define new auth schemes, but that requires writing it down, and getting it registered.

[Константин Ван]

@JulianReschke You can think of submitting a reCAPTCHA solution token as authentication to be authorized for a certain resource. There's nothing wrong about having Authorization: reCAPTCHA <token> requests and WWW-Authenticate: reCAPTCHA responses that you just make up and only your server knows. You don't have to register it to some kinds of standard institutes.

[Julian Reschke]

<greenbytes.de/tech/webdav/rfc7235.html#rfc.section.5.1.1>: "Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1)."

[Medinoc]

@JulianReschke I would have thought values prefixed with X- would be admissible, but looks like not. The big problem is, there's no value listed for "Just show the damn HTML payload so the user can authenticate manually", as if the header were planned for every possible client software but browsers.

[Julian Reschke]

Hm, no. HTTP auth works just fine with browsers. And it wouldn't be hard to define an auth scheme compatible with HTML forms; the problem is that browser makers do not want to make HTTP auth more versatile.