use http 404 instead of deny for restricted locations

[wbob]

this is a proposal to harmonize the restrictions with the other deny-location blocks, already making use of a 404 status - and make it more robust and foolproof.

I stumbled on this with shopware 5.4 usage of a dotenv file. In development setups for sharing with trusted parties, an auth_basic or some ip allow is used. With the nested "deny all" via include file, the parent server{} declaring a satisfy all/any, those paths will be accessible for those fulfilling the criteria(s). Though this is of no concern in a production setup, this is a minor pitfall in development.

I've come to the conclusion a return 403 (or even a 404, as the rfc suggests for purposes of no information disclosure) is less error prone if I know the ressource should under no circumstances be accessed via http, even if "authenticated" in a general context.

[emilv]

404 is definitely the way to go if the file is never accessible. There simply should not be a file at the location from the web browsers' point of view. We need to let go of this mental image that "everything on the server is accessible, except the files that we blacklist". The only things that are accessible are resources that are part of the external application interface, and those are not "files".

[bcremer]

Sounds reasonable to me. Thanks for your PR :+1:

[wbob]

.. and thank you for continuing to shepherd the inofficial shopware nginx config :+1: