Opened 15 years ago
Closed 15 years ago
#10930 closed defect (bug) (fixed)
Wordpress incorrectly returns a 200 on a 404
Reported by: |
|
Owned by: |
|
---|---|---|---|
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)
Change History (7)
#1
@
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
#3
@
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.
#4
@
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?
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.