Last modified: 2014-02-06 18:02:46 UTC
While every nonexistent page returns 404, the nonexistent but populated categories don't return 404. Not sure if it's intended behavior (if yes, why?), so reporting at least for reference.
Categories are not articles. Categories are lists of pages. If a category has pages in it. Then why should it be a 404? There's content there. Category page text is nothing but a worthless description. It matters not whether the description exists or not.
1) The category text is definitely not a worthless description (and even if the description text was, there is still categorization itself, which is indeed important, plus interwiki). 2) Without returning 404 it can't be recognized that the category does not exist.
The category does exist. Pages are using it.
The category *page* does not exist though.
Testcase welcome, for future reference.
(In reply to comment #4) > The category *page* does not exist though. The page is irrelevant. Whether the page exists or not. There is still something MW has to display at that url. Hence, it is not a 404. A 404 indicates that absolutely nothing exists there. The only stuff outputted is stuff global to the whole site and stuff relevant to an error. That behaviour is incorrect when MW is outputting something for that page.
(In reply to comment #5) > Testcase welcome, for future reference. That's quite hard because people obviously create those categories or remove them from pages. So having a stable permalink to nonexistent but populated category is pretty much impossible.
Anything red from https://en.wikipedia.org/wiki/Special:WantedCategories would work as a test case.
I think this bug should be wontfixed (per daniel). If the behaviour being asked for was present, I would consider that to be a bug.
Bug is, when there is an inconsistent behavior. 404 is (apart from obvious 404 cases) returned when the *page* does not exist = there is no such row in page table. Populated categories do not have a row in page table because the category page does not exist. So it should stay consistent with the rest.
s/Populated categories/Nonexistent populated categories/
(In reply to comment #10) > Bug is, when there is an inconsistent behavior. 404 is (apart from obvious > 404 > cases) returned when the *page* does not exist = there is no such row in page > table. Nonexistent populated categories do not have a row in page table because > the category page does not exist. So it should stay consistent with the rest. No, 404 is not a function of what is inside the database. 404 is something decided by whether the controller of the request's output decides it should be a 404. Be that Article, SpecialPage, ImagePage, CategoryPage, or some other custom controller. Different namespaces can have different behaviours. For example, Special: pages don't exist inside the database, whether it's a 404 or not is entirely decided by the class making the output. And likewise for categories -- which have content in the form of a list of pages that are inside the category -- 404 is decided based on if both the page does not exist AND there are no pages inside the category to display. ImagePage could be another special case given it too is more than just an article.
Where in the code/db doesn't really matter. What matters is the meaning of the error. 404 means resource not found. If we return a 404, it should be entirely safe (albeit annoying beyond belief) for a web browser to replace our 404 page with its own error page. This would not be the case if there are category entries. If there are entries in the category, we are returning actual content, hence 200 is the appropriate status code. ---- As an additional technical motivation. Returning 404 on such a page would prevent them from being indexed by search engines. I believe most people would want such a page to be indexed.
I agree with Brian and Daniel. I'm going ahead and WONTFIXing this now.
