Make WordPress Core

Opened 13 years ago

Last modified 5 years ago

#17619 new enhancement

Soft 404 at /wp-content/plugins/

Reported by: miqrogroove's profile miqrogroove Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: General Keywords: has-patch 2nd-opinion
Focuses: Cc:


/wp-content/plugins/index.php would be better written with a proper 404.

header('HTTP/1.0 404 Not Found'); // Silence is golden.

Attachments (3)

17619.diff (341 bytes) - added by BenChapman 13 years ago.
Adds a 404 error message
17619.patch (664 bytes) - added by jakub.tyrcha 13 years ago.
17619.2.patch (1005 bytes) - added by jakub.tyrcha 13 years ago.

Download all attachments as: .zip

Change History (19)

#1 @johnbillion
13 years ago

Shouldn't it technically be a 403?

#2 @miqrogroove
13 years ago

Technically, there is nothing in the response entity, so either 403 or 404 is appropriate.

#3 @toscho
13 years ago

  • Cc info@… added

Why not 410? Nobody should come back, no?

#4 @BenChapman
13 years ago

As per RFC2616 if a reason is to be given for denying access then 403 should be used, otherwise 404 should be used. In this case I would say 403 would be the better response code with a reason included for forbidding access.

Version 0, edited 13 years ago by BenChapman (next)

13 years ago

Adds a 404 error message

#5 @BenChapman
13 years ago

  • Cc admin@… added

#6 @solarissmoke
13 years ago

If this is going to change, then it should change for all wp-content directories, i.e., /themes and /uploads also.

#7 @kirasong
13 years ago

  • Type changed from defect (bug) to enhancement

13 years ago

#8 @jakub.tyrcha
13 years ago

Why should we include this in the uploads/ directory as well?

#9 @edwardw
13 years ago

  • Keywords has-patch added

I feel that a 403 would be a more appropriate response since there is actually a directory, just not that one permit access to access it.

Last edited 13 years ago by edwardw (previous) (diff)

#10 @chriscct7
10 years ago

  • Keywords dev-feedback added
  • Severity changed from minor to normal

#11 @DrewAPicture
10 years ago

@nacin: Possible to get a yea or nay here?

#12 @chriscct7
9 years ago

  • Keywords needs-nacin added

#13 @dd32
9 years ago

  • 404 = Technically wrong, it's not a missing resource, the resource is deliberately empty
  • 403 = Slightly more appropriate, has precedent in [30356]
  • 200 = Entirely valid IMHO, It's just an empty response to prevent directory listings.

If a committer feels strong enough for a 403, go for it.

#14 @swissspidy
8 years ago

  • Keywords dev-feedback needs-nacin removed

#15 @desrosj
5 years ago

#46286 was marked as a duplicate.

#16 @desrosj
5 years ago

  • Keywords 2nd-opinion added
  • Milestone set to Future Release

Copying the detailed description over from #46286, which was just closed as a duplicate:

Direct requests to system file structures/folders (e.g., currently return a blank page with a 200 HTTP status. This informs search engines and agents that the page/state is 'okay', which may result in them being crawled, indexed, or otherwise exposed.

This causes a number of SEO and analytics headaches, and, is generally poor practice.

Whilst these directories/files technically do exist, and therefore arguably should return a 200 status, the important thing to consider is that no user-facing page/content exists at the URL. We're not trying to represent the 'physical' file structure of the site (which we're already extremely abstracted from), we're trying to signpost what is, or isn't, a valid page/response. That an actual file/folder resides at the requested URL is irellevant.

In the short-term, we should simply set a 404 header in all 'Silence is golden' templates.

In the long-term, we should aim to find a way to allow all request to 'Silence is golden' files to return the 404 template of the active theme. This may come with complexities, where we can't rely on system configurations/capabilities or folder structures to be consistent between sites.

As an aspiration, we should aim that all requests to a WP site return an appropriate HTTP status and experience based on the user's context, regardless of the actual file/directory structure.

Props @jonoaldersonwp, @vanyukov, @santilinwp for their discussion and work over there.

Note: See TracTickets for help on using tickets.