3

What is the correct way to fail when the user provides a wrong or not applicable value for a query parameter?

  1. with a HTTP 406 Not Acceptable status code and a page describing the issue
  2. with a HTTP 400 Bad Request status code and a page describing the issue
  3. a page with no special HTTP status code but giving possible solutions to the issue

Example of not applicable query parameters would be a order=123 where either order=desc or order=asc are expected to decide how to print a list. Giving a non-date value to a parameter that expects a formatted date could be another example.

Normally, sites would simply act as if the default value was given, but this could be a problem if someone links to my site with a wrong query parameter value and search engines start indexing it.

1

4 Answers 4

4

For UX it's best to just use default values instead. Your case seems kind of rare. Has it been a real problem in some cases?

Thinking out of the box, one solution could be 301 moved permanently reply pointing to the URL with the default value. That would

  • Solve the problem with search engines.
  • Give user direct feedback on the incorrect parameters, actually making UX even better.
1
  • 302 (temporary redirect) might be a better choice here than 301 (permenant redirect), since browsers (and presumably search engines) cache permenant redirects indefinitely (or at least for a long time), meaning that if the invalid query string value becomes valid one day (e.g. you add a new value for sort, say), then the browser will still continue to redirect and won't send a new request to the server for that URL. Nov 3 at 16:58
2

406 would be incorrect, as the standard defines (Emphasis mine):

The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.

So no, 406 is only about the accept header, not query parameters or anything else.

2

Assuming the default value is not bad. There are several ways you could handle search engines:

  • Redirect to remove badly formed or missing parameter values. All of the following could get 301 permanently redirected to /page.html?order=desc:
    • /page.html
    • /page.html?order=
    • /page.html?order=123
  • Use the canonical meta tag without redirecting. This tells search engines which URL is the correct one to index when several URLs have duplicate content. Search engines don't usually care much about the order of the items on the page, so you could make the canonical URL the version without the order parameter at all. All your versions of the page could have this in the <head>: <link rel="canonical" href="https://example.com/page.html">

I wouldn't use any 4xx status codes for this situation. Use 301 redirects or use the tools that the search engines supply.

1
  • 302 (temporary redirect) might be a better choice than 301 (permenant redirect) in this case, since browsers (and presumably search engines) cache permenant redirects indefinitely (or at least for a long time), meaning that if the now-invalid-query-string-value becomes valid one day (e.g. you add a new value for order, say), then the browser will still continue to redirect and won't send a new request to the server for that URL. Nov 3 at 20:04
1

It would depend on the situation, and cause of the incorrect value, and there isn't really a 'catch-all' for incorrect query string parameter.

In your example, I would use a 400, as 123 being entered for order is a completely inappropriate value, but if the query parameter was incorrect from an old link still pointing to my site after I had changed the query string structure, I would be more inclined to a 301.

I would say assess the cause the same way you would for a normal URL structure, and not to give query string parameters any special treatment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.