WordPress.org

Make WordPress Core

Opened 12 years ago

Closed 12 years ago

#7808 closed defect (bug) (invalid)

Incorrect HTTP on 404

Reported by: ojreadmore Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: Cc:

Description

I have found with 2.6.2 that a nonsensical URL will give a 200.

For example,
http://codex.wordpress.org/foobar

Change History (10)

#1 @greaterweb
12 years ago

I did a little research on this and I can point you in the right direction to get a jump start towards a fix.

In wp-includes/classes.php, when the script is looping through the rewrite rules it finds a match with two rewrite rules it shouldn't.

The two rules are:

(.+?)(/[0-9]+)?/?$

and

([^/]+)(/[0-9]+)?/?$

The pattern is matched with preg_match on lines 104-105. With the match found, $error is unset at 125. This kills the 404 header from being sent. Further along when WP discovers the page does not exist, the 404 template is served up. The issue is the 200 header is still sent to the browser.

I tried to do a few inline fixes to $match when either of those rules were presented. I was able to get the proper header to serve up for some situations, but not all.

On a related note, if the permalink structure is set to default, 404's don't work at all. 200 header sent and the home page gets served.

#2 @Viper007Bond
12 years ago

The Codex is powered by MediaWiki. Why was it used as an example? o_O

And it works at least part of the time: http://www.viper007bond.com/foobar (I get a 404 there)

#3 follow-up: @lloydbudd
12 years ago

What are examples that demonstrates the issue?

#4 @Viper007Bond
12 years ago

  • Keywords reporter-feedback added

#5 in reply to: ↑ 3 @greaterweb
12 years ago

Maybe I had been staring a bit too long at my monitor that night. I thought I had confirmed such existence of a problem with 2 or 3 sites I have running 2.6.2., hence going the lengths I did to break down some of the WP code.

After rechecking things now, everything appears to be returning the proper 404 header. Very odd to say the least.

However, it does appear what I had stated previously about when the permalink structure is set to default (eg. ?p=123), there doesn't appear to be any 404 handling in place. Meaning, the homepage gets served up accompanied by a 200 header. I only discovered the existence of the issue when playing around with various permalink structures in an attempt reproducing the initial 404 issue posted.

Should there be 404 handling in place with the default permalink structure?

#6 @lloydbudd
12 years ago

  • Resolution set to invalid
  • Status changed from new to closed

greaterweb, thanks for doing the additional resource.

The new issue sounds possibly theme specific. It looks like it affects the default theme. It does seem like a bug, but I'm not confident anyone will be eager to fix it for the old bird of a theme ;-)

Feel free to open a new ticket for that issue, if you are passionate about it.

#7 @lloydbudd
12 years ago

  • Milestone 2.8 deleted

#8 @ojreadmore
12 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

I forgot to say that I'm using wordpress MU 2.6.2
I observe this behavior on a brand new install of MU.

http://foo.com/bar (301) -> http://foo.com/bar/
http://foo.com/bar/ (200), however bar, nor bar/ exist.

I tried with different themes too.

#9 @DD32
12 years ago

I forgot to say that I'm using wordpress MU 2.6.2 I observe this behavior on a brand new install of MU.

In that case, It might be better to take it to the WPMU trac instead: http://trac.mu.wordpress.org/

#10 @mrmist
12 years ago

  • Keywords reporter-feedback removed
  • Priority changed from high to normal
  • Resolution set to invalid
  • Severity changed from major to normal
  • Status changed from reopened to closed

Closing as invalid as before. MU issues should go to the MU trac.

Note: See TracTickets for help on using tickets.