Soft 404 at /wp-content/plugins/

[miqrogroove]

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

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

[johnbillion]

Shouldn't it technically be a 403?

[miqrogroove]

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

[toscho]

Why not 410? Nobody should come back, no?

[BenChapman]

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.

[BenChapman]

Adds a 404 error message

[solarissmoke]

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

[jakub.tyrcha]

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

[edwardw]

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.

[DrewAPicture]

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

[dd32]

• 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.

[desrosj]

#46286 was marked as a duplicate.

[desrosj]

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.