11

Which HTTP status code would you return to indicate an unsupported browser? I've looked through the 4xx (client error) codes but none seem to fit.

Yarin
  • 173,523
  • 149
  • 402
  • 512

2 Answers2

18

403 Forbidden is the most appropriate.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4 says:

The server understood the request, but is refusing to fulfill it.

400 Bad Request is not a good fit because it implies the request itself is malformed, which is probably not true.

If you are building a website, however, it is not a good practice to forbid specific web browsers in this way. Try to build a website that is compliant with all the browsers used by your audience. If you are building an HTTP API, then that's a different story, and you should use a secure mechanism for authorizing clients. If that's what you need, consider OAuth.

EDIT July 2015: The newer RFC 7231 elaborates its explanation of 403, making it more clear that it is okay to use even when it is not a credential authorization issue.

https://www.rfc-editor.org/rfc/rfc7231#section-6.5.3 (bold added by me):

The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).

If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.

Community
  • 1
  • 1
Andre D
  • 4,585
  • 1
  • 19
  • 26
  • @AndreD- I think you're right- Since we're forbidding older browsers, 403 is perfectly appropriate. Thanks! – Yarin Nov 06 '13 at 03:10
  • 1
    @AndreD- "Try to build a website that is compliant with all the browsers used by your audience." Thanks, but we build HTML5 web apps. As long as old IE browsers still roam the earth trying to accommodate every browser is a pipe dream. – Yarin Nov 06 '13 at 03:15
  • @Yarin Right, we can't get HTML5 web apps to function in all browsers, but I would avoid forbidding browsers if the method of doing so is to check the user-agent string. I'd rather start with an approach where we check the actual HTML5 feature support before deciding to allow or forbid, and for all I know that's what you're doing already. – Andre D Nov 06 '13 at 19:03
  • what about 417?? Expectation Failed – Sheik797 Jul 04 '15 at 06:28
  • @AbhishekLal 417 Expectation Failed is not relevant here. It is used by a server to give a negative answer to a request with an "Expect" header https://tools.ietf.org/html/rfc7231#section-5.1.1 – Andre D Jul 05 '15 at 23:30
1

400 (bad/malformed request) is the only one that fits... somewhat

Tony
  • 460
  • 1
  • 7
  • 20
  • I thought that might be it at first, but looking at the **[RFC](http://tools.ietf.org/html/rfc2817#section-14.42)**, it says its purpose is "to indicate that a TLS-secured connection is desired or necessary". – Yarin Nov 05 '13 at 18:29
  • 1
    Yeah, I think you are right. How about a 400 (bad/malformed request) status code? I think it's the only one that fits... somewhat. – Tony Nov 05 '13 at 18:36
  • Yeah I think 400 is what I'm gonna go with. Thanks, if you update your answer I'll give you cred. – Yarin Nov 05 '13 at 18:51
  • Updated! Glad I could help, Yarin. – Tony Nov 05 '13 at 19:05
  • 1
    @Andy- Turns out Andre makes a good point about using a 403 in this case, I'm gonna go with that. Thanks for your effort though. – Yarin Nov 06 '13 at 03:19