Is HTTP 404 appropriate for out of range page number on paged content?

Question

I have a site that is mainly showing a paged list of content (articles, data element's, etc.), and I'm wondering about returning HTTP 404 when user navigates outside of the available list range (eg. by hand edited url).

Some sites just display "No results/Page number out of range" and some return additionally return HTTP 404 status.

What's your take on that, and why?

UPDATE

It's not and api response. This question is in regard to user viewed pages that among other things show a list/table in the main area.

UPDATE

Borderline example: 1'st page is a page out-of-range because no data for the shown list exists yet.

Should I show 404? If it where search result's I wouldn't mind... but for plain viewing of paged list/data table seems harsh.

Example: the first day of Stack Overflow run and no questions exist yet, you hit the home page and what, 404 or just a 200 with "No questions yet" message?

Dardan

Answer 1

I would go for 404 when page number is != 1, regardless where the page number is placed in the URI (query string or in the path), and go for the soft 404 when there's no results but page number is exactly 1 or not given.

Why?

Result set page 1 is exists as a landing page for the results set (even search results -- see Google here), so it's found and exists (if not for showing result set) to tell you that there is no data in the result set.

Then any result set page number outside result set's range is not found, there's no meaningful point for these page/resources to exist, hence 404. If one should argue that they exist to convey a message "No MORE data", hence they are meaningful, hence need to be indexed - search engine nightmare!

HTTP 400 Bad Request is bad choice because it would suggest that request can never be correct.

HTTP 400 Bad Request - request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications

404 Not Found is vague about this case, and in this case can be IMO interpreted both ways

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

Dardan

Answer 2

I'd say this is absolutely a case for a 404. It's a request for a resource that doesn't exist. Whether the general page/script used to display the items is irrelevant.

Footwall

Borderline example, 1'st page and no data in the list. Should I show 404? For search result's I wouldn't mind... but for this case it's harsh. Example: the first day of Stack Overflow existence and no questions exist yet, you hit the home page and what, 404 or just a 200 with "No questions yet" message? – Dardan

@Woo I'd say that depends a bit on your setup. What kind of URLs are in play? What do they look like? What kind of lists do they query? – Footwall

Currently I'm listing teachers attached to a shool entry, and URL like eg. /School/XXX/Teachers/?page=Y – Dardan

@WooYek hmmm. Good question. Maybe, strictly spoken, a request to a page should be returned with a "bad request", as that is really a "range" thing as argued in some other answers. I'd still go with a 404. I'd create an index page (School/xxx/Teachers) that is always available (to say "no entries currently" in the body) but any reference to ?page=xyz would return a 404 if the page is out of range. A request to a non-existent item like a specific teacher (/Teachers/?id=123456) would definitely be a case for a 404. – Footwall

For missing specific object page I have no doubt, it's 404 case. But the listing page is implemented differently and preference between 404 and soft 404 is divided. I think now that it should be decided by case basis, accounting what you listing and how can it affect usability and robots. – Dardan

@Woo that is probably the most sane way to go. – Footwall

Answer 3

Yes, if it's an API, as 4xx errors indicate a temporary lack of resource, that may exist later on. If it's not an API, I'd suggest any 404 page is a little more user friendly (e.g. like http://www.didcot.com/forum/?read=1234567 ).

Pessimist

Answer 4

-- when user navigates outside of the available list range.

You should not provide out-of-range link. In the last page of results, do not show a 'next' link. Well, I guess you are not doing that. But somebody else can link to your out-of-range page, which brings us interesting question:

As already said, 404 should be returned for non-existent resource. The real question is: "What makes a resource?"

I would say, that if the number of results varies often (e.g. daily) and can also decrease (so result page #9 may exists today but not necessarily tomorrow), the listing/search functionality as a whole makes a resource, not single result page, which merely represents a particular state of the resource.

Instead, if the number of results can only increase, i.e. the objects being listed are not volative but permanent, it makes sense to show 404 for out-of-range pages, since existing result page is more like a resource, i.e. document meant to stay there.

Generally, I think there are no universal answer but the decision is up to webmaster, because no clear enough specification exists. One should remember that status codes are returned primarily for non-human clients (robots, search engines) who are unable to understant the content of page, so in practise this is mostly an SEO issue.

Just to mention, out-of-range result pages are given a status 200 by Google: (not that Google is a god.)

$ curl -s --head -A 'Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; fi-fi) AppleWebKit/531.21.11 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10' 'http://www.google.com/search?q=stackoverflow&start=1000' | grep ^HTTP
HTTP/1.1 200 OK

Aglimmer

I agree it's a preference, and robots are here the deciding factor, that's I'm in favor of 404. But since there shouldn't be any out-of-range-links soft 404 would not hurt any robot's. Again if user is hand editing URL, we do not have to go soft on them :) ... ehhh, I flip a coin. – Dardan

Answer 5

From a RESTful approach I think that the correct status code will depend on the data model.

If the page is itself a resource, and is therefore part of the path (e.g. /resource/page/5), a 404 would be an appropriate code as the resource effectively does not exist.

However, if the pagination doesn't belong to the data model (which is most common, e.g. /resource?page=5), a 404 could be a misleading response.

I usually use 416 Range Not Satisfiable in these cases to make it explicit that the resource exists but the request is out of range.

Saxony

Answer 6

If it's your querystring that tells what page to return, 404 might not be appropriate. If it's not in your querystring, then the document doesn't exist and 404 is definitely appropriate.

Recursion

So URL is like /School/XXX/Teachers/?page=Y - then return soft 404, if /School/XXX/Teachers/Page/Y/ - then return 404. Correct? – Dardan

Answer 7

For a requested page that is higher than total pages, I would consider redirecting to last / maximum page with one of these codes:

• 302 "found"
• 303 "see other"

Reasons would mostly be: if you display 10 items par page, the pages get indexed by search engines, then you decide to change site layout and display 20 items per page, then the indexed high number of pages would otherwise return 404 errors.

Same if you delete records from your site, instead of showing a 404 on page 120, redirect to last possible page, e.g 100 and inform by a redirect code.

Tolliver

Answer 8

Well i would not return 404 because the page in general is found (like display.php?page=62).

In my opinion the best solution is to tell the user "Page number out of range/not availible" and a link to the last existing page or an history.back() link.

HTTP Code 400 may be the thing you are looking for.

Adalbertoadalheid

Note that the query parameters are part of the URI and the 404 applies to the whole URI, not just the path part. Also, 400 is probably a bad choice here. – Gittle