WordPress.org

Make WordPress Core

Opened 8 years ago

Last modified 4 weeks ago

#17619 new enhancement

Soft 404 at /wp-content/plugins/

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

Description

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

<?php
header('HTTP/1.0 404 Not Found'); // Silence is golden.
?>

Attachments (3)

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

Download all attachments as: .zip

Change History (19)

#1 @johnbillion
8 years ago

Shouldn't it technically be a 403?

#2 @miqrogroove
8 years ago

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

#3 @toscho
8 years ago

  • Cc info@… added

Why not 410? Nobody should come back, no?

#4 @BenChapman
8 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.

Last edited 8 years ago by BenChapman (previous) (diff)

@BenChapman
8 years ago

Adds a 404 error message

#5 @BenChapman
8 years ago

  • Cc admin@… added

#6 @solarissmoke
8 years ago

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

#7 @mikeschroder
8 years ago

  • Type changed from defect (bug) to enhancement

@jakub.tyrcha
8 years ago

#8 @jakub.tyrcha
8 years ago

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

#9 @edwardw
8 years ago

  • Keywords has-patch added
Version 0, edited 8 years ago by edwardw (next)

#10 @chriscct7
5 years ago

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

#11 @DrewAPicture
5 years ago

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

#12 @chriscct7
4 years ago

  • Keywords needs-nacin added

#13 @dd32
4 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
4 years ago

  • Keywords dev-feedback needs-nacin removed

#15 @desrosj
4 weeks ago

#46286 was marked as a duplicate.

#16 @desrosj
4 weeks 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., https://yoast.com/app/wp-content/) 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.