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

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 view开发者_StackOverflowing 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?

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.

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.

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

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

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.

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.