Make WordPress Core

Opened 15 years ago

Closed 15 years ago

#10930 closed defect (bug) (fixed)

Wordpress incorrectly returns a 200 on a 404

Reported by: dtsn's profile dtsn Owned by: joostdevalk's profile joostdevalk
Milestone: 3.0 Priority: normal
Severity: normal Version: 2.9
Component: General Keywords: has-patch needs-testing
Focuses: Cc:

Description

Wordpress is incorrectly returning a 200 status code on a 404 (or a possible 403).

Any URL ending with a ?p=<post id which doesn't exist> returns a 200 instead of a 404. Or if it is a preview post it should return a 403, Forbidden.

For example:

http://mashable.com/?p=23489675213948613209486
http://www.techcrunch.com/?p=160900
http://www.mattcutts.com/blog/?p=160900
http://yoast.com/?p=160900

Attachments (2)

classes.patch (515 bytes) - added by joostdevalk 15 years ago.
Patch
10930.diff (1.1 KB) - added by dd32 15 years ago.

Download all attachments as: .zip

Change History (7)

#1 @Denis-de-Bernardy
15 years ago

  • Component changed from HTTP to General
  • Milestone changed from Unassigned to Future Release
  • Owner dd32 deleted
  • Type changed from defect (bug) to enhancement

#2 @dd32
15 years ago

  • Keywords 404 removed
  • Type changed from enhancement to defect (bug)

Pretty sure theres a few reports of this in trac.

Pretty sure it generally comes down to a server configuration under which, its impossible to set the 404 header, or a caching server not 404'ing it, and I'm also wondering if certain cache plugins cache the 404 header or not..

enhancement -> defect: WordPress already does do 404'ing headers when it hits a 404 condition as long as the server allows it.

#3 @joostdevalk
15 years ago

  • Keywords has-patch needs-testing added
  • Owner set to joostdevalk
  • Status changed from new to accepted
  • Version changed from 2.8.4 to 2.9

It doens't do this correctly at all, and it has nothing to do with server settings. is_single is set to true, independent of whether there are actually any posts there. Handle_404 in classes.php doesn't handle 404's if permalinks are disabled or if the link that was opened isn't a permalink.

I've got a patch, which I will attach in a second, that fixes this, the only "issue" is that right now, if you open page_id=500 and 500 is actually the id of an attachment, it'll redirect to the attachment. With this patch in place, it won't do that anymore. To be honest I think that's how it SHOULD work, but it's good to know.

Also, a preview page should throw a 404 if you're not logged in, otherwise it would expose that there actually IS a post with that ID but it's not published yet, this patch takes care of that as well.

@joostdevalk
15 years ago

Patch

#4 @dd32
15 years ago

In addition to this, A tonne of Notices are thrown when rewrite permalinks are not enabled due to functions relying on is_404 to detect if $posts will be populated or not..

I cant fault this patch i'm about to submit.. I didnt see the real point in joostdevalk's duplication of the code.. But i understand there was a issue he had with my approach to this (tried it first).

If joostdevalk could have a test with this patch and report what doesn't work as expected?

@dd32
15 years ago

#5 @nacin
15 years ago

  • Milestone changed from Future Release to 3.0
  • Resolution set to fixed
  • Status changed from accepted to closed

MarkJaquith FTW in [13315]

Note: See TracTickets for help on using tickets.