40

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).

Markus Malkusch
  • 7,738
  • 2
  • 38
  • 67

3 Answers3

18

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

Community
  • 1
  • 1
Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
  • 3
    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 – John Aug 16 '16 at 17:45
  • Well, 401 implies presence of a defined authentication scheme. Don't make up a scheme just to be able to use 401. – Julian Reschke Aug 17 '16 at 23:27
  • 2
    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. – John Aug 22 '16 at 19:58
  • @JulianReschke Why not making a custom `auth-scheme` up? [RFC 7235](https://tools.ietf.org/html/rfc7235#section-4.1) says “okay” with that. – Константин Ван Aug 18 '19 at 13:27
  • @КонстантинВан could you be more specific? Yes, you can define new auth schemes, but that requires writing it down, and getting it registered. – Julian Reschke Aug 19 '19 at 10:50
  • @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 ` 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. – Константин Ван Aug 19 '19 at 15:35
  • : "Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1)." – Julian Reschke Aug 20 '19 at 04:06
  • @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. – Medinoc May 18 '22 at 12:39
  • 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. – Julian Reschke May 19 '22 at 13:16
3

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.

Levi Dulstein
  • 147
  • 4
1

FWIW I'm using 498.

wikipedia: Code 498 indicates an expired or otherwise invalid token.

498 Invalid Token (Esri) Returned by ArcGIS for Server. Code 498 indicates an expired or otherwise invalid token.[74]

Legal Weed Dude
  • 11
  • 1