WordPress should not generate feeds for 404 pages

[solarissmoke]

Say I try to visit: http://my.blog.tld/non-existent-slug/, (where non-existent-slug is not a valid slug) I get a the normal 404 template.

However, if I try to visit http://my.blog.tld/non-existent-slug/feed/, then the response is a bit weird. A 404 response header is sent but the content is nonetheless sent through the feed template. And so you get something like this:

<?xml version="1.0" encoding="UTF-8"?><rss version="0.92">
<channel>
  <title>A Sandbox &#187; Page not found</title>
  <link>http://my.blog.tld</link>
  <description>Just another WordPress weblog</description>
  <lastBuildDate>Mon, 19 Apr 2010 11:17:05 +0000</lastBuildDate>
  <docs>http://backend.userland.com/rss092</docs>
  <language>en</language>
  <!-- generator="WordPress/3.0-beta1" -->
</channel>
</rss>

Assuming this isn't intentional (I can't think why it would be), this should be changed so that the content is the normal 404 template.

[solarissmoke]

The problem is that in the template loader, do_feed() is called before calling theme files (where 404 is checked). I propose adding an is_404() check before doing feeds.

[solarissmoke]

Looking more closely, the WP_Query::set_404() function deliberately does not reset the is_feed boolean like it does with everything else when a 404 is found, suggesting that for some reason this is intentional.

Any comments on why this might be the case? I think a 404 should go through the 404 template regardless of what is requested. if_feed isn't really valid because even though the query might look like it is for a feed, no such resource exists and therefore we shouldn't assume it is a feed.

[dd32]

Looking more closely, the WP_Query::set_404() function deliberately does not reset the is_feed boolean like it does with everything else when a 404 is found, suggesting that for some reason this is intentional.

I'd say that'd be for not 404'ing valid feed url's, For example, the Feed url of a empty category, The feed is a valid feed, even if it has no posts.

[solarissmoke]

Replying to dd32:

I'd say that'd be for not 404'ing valid feed url's, For example, the Feed url of a empty category, The feed is a valid feed, even if it has no posts.

No, the issue isn't with empty feeds. If you try to access a feed for an empty category you just get an empty feed (status 200), which is fine.

The problem is when you try to access the feed for a non-existent category, then you still get a feed template, which doesn't make sense, instead of a proper 404 page.

I think is_feed() and is_404() should be mutually exclusive. You cannot have both returning true at the same time.

[solarissmoke]

Tracked down the origin of this to ​3019, where the issue was indeed that empty feeds were getting 404's.

However, the current behaviour isn't consistent because feeds for empty categories return a 200 status with an empty feed, but some other feeds (e.g for global comments feed if there are no comments) are returning a 404 - which is wrong because the feed is valid, it's just empty.

The behaviour ought to be: if the feed is valid, but empty, return an empty feed with status 200. If the feed is invalid (because the slug/category etc doesn't exist), then return a 404 page in HTML. In either case, is_feed() and is_404() cannot be true at once.

[dd32]

No, the issue isn't with empty feeds.

I think you mis-understood me, I was referring directly to set_404() not setting 404's for feeds.

My understanding is that its to allow for the feed template to continue being loaded even when no posts exist for the request, but the actual request is still valid.

For example, An empty category feed should still return an empty feed. which is different from a non-existant category, or resource, which this is about.

---

In either case, is_feed() and is_404() cannot be true at once.

Well it can, is_404() being true refers to there being no posts/pages/etc to return for the current request, that does not mean that the request is a 404'able request however (In other words, WordPress is_404 is not the same as a 404 HTTP response in all cases). See WP::handle_404() for some cases where it doesnt pass it through.

I do agree, that is_feed() should be false for a non-existant resource however.

[dd32]

From what i can see, Removing the changes made in #3019 has no side effects under todays trunk other than causing the themes 404 to be served for non-existant objects feeds' Which is how i'd expect it to be.

[solarissmoke]

Replying to dd32:

From what i can see, Removing the changes made in #3019 has no side effects under todays trunk other than causing the themes 404 to be served for non-existant objects feeds' Which is how i'd expect it to be.

Agreed. Do you think that change can be committed?

Meanwhile the issue of sending 404s rather than 200s to some valid feed requests because they have no content will still remain. I'm working on a possible patch but that can be a separate issue.

[dd32]

Meanwhile the issue of sending 404s rather than 200s to some valid feed requests because they have no content will still remain.

Any examples of URL's which send 404's? I'm not aware of any, but if you can point some out, they'll be fixed

Agreed. Do you think that change can be committed?

I'm going to check with Ryan or someone else who was around at that time and knows some of the back story first, but i see no harm in it.

[solarissmoke]

Replying to dd32:

Any examples of URL's which send 404's? I'm not aware of any, but if you can point some out, they'll be fixed

There are two cases (I thought there were more but it was because I was messing around with query.php): if you try to access the global posts feed or global comments feed when there are no posts or no comments, then you get 404s.

This is a minor case however, as it only happens if you delete all posts or all comments on the blog. So I don't know if it's actually worth fixing.

[hakre]

As the reporter signalled uncertanity of beign worth to fix, I assume it's at least clarified, that it's not explicitly worth fixing. I close as wontfix. If someone else recommends fixing this, please reopen.

[solarissmoke]

Refreshing the patch - assuming nobody disagrees that is_404 and is_feed should be mutually exclusive

[solarissmoke]

Do no preserve is_feed for 404 pages

[nacin]

Needs feedback.

[nacin]

Change came in #3019, [4096].

Original issue seems to have been handled elsewhere, it appears.

[markjaquith]

Punting for now. I don't think this should change. If you ask for a feed, you should get a feed, even if it's an empty feed. We'll see what the other devs think.

[SergeyBiryukov]

Related: #9611

[stevenkword]

Relates to #28134

[stevenkword]

This is a duplicate of #30210, which is currently milestoned for 4.5.

[stevenkword]

Duplicate of #30210.