Its all very confusing. Writing headers to the file actually makes it more confusing (for me). Is it even compatible with setting headers for site or admin or both?

Here is a PR to make sure only the global headers are written.: #25717 Good spot ?

We also now have the situation that we have rules set in the htaccess, rules set in the plugin, and rules set in the component and no way to see in one place all the rules that are being applied. This will make debugging a faulty rule very hard.

Well usually you should set the CSP in the CSP Component an all other headers are set in the plugin. Well you can overwrite them from the plugin too but then you should know what you are doing. Do you have a suggestion to deal with that? I personally don't see an issue how it is done now as there is a clear split between plugin and component; CSP should be set in the component and all others in the plugin.

There is no way to delete all the headers from the htaccess. So once they have been written to the htaccess if you then disable that option no changes made to the settings will be applied

Well what would you suggestion about this be? Here is a issue about this question too. The hard part is with web.config file as you can't detect whether the header was set by the plugin or the admin or other tools.

Stick to handling it in PHP only.

If the htaccess file is not writeable then you get a popup which should contain the text to copy etc. BUT its not scrollable so its not possible to copy it all

Stick to handling it in PHP only.

What do you mean by that, i'm confused?

its not scrollable so its not possible to copy it all

A Patch can be found here: #25719 Thanks for the report ?

The htaccess changes do not make it clear that these are only the "global" settings and that there may be others set in the plugin or in com_csp which may replace the ones in the htaccess

MANAGED BY PLG_SYSTEM_HTTPHEADERS DO NOT MANUALLY EDIT! - START

I agree with @mbabker, handle it in PHP only.

Well what do you mean by handle it in PHP only.

The disadvantage of not using .htaccess is that the rules only being applied when Joomla runs, htaccess enforces that on the server level.

I like to edit my .htaccess myself, I don't need a plugin doing that. I don't want to imagine what happens with all those users having no ssh access with their hosting package and we have a bug which ruins their .htaccess file so they get a server error 500. I can fix that per ssh, but they have to call their provider.

or use ftp, or use their hosts control panel

yes, if they know about it ;-)

How many of the headers are you actually concerned with if a request goes to a non-Joomla resource on the server? Can Joomla reliably manage writing config files for all supported web servers without losing user data in those files? Core has avoided having a web server config in its interface and I would not monkey patch partial support in a plugin (if you want to do it, which I don’t think it is a web application’s responsibility to give this to users, it should be a proper API that is hookable throughout the system).

@richard67 makes a very good point. Its the same reason why in the training videos for admintools I stress repeatedly that the user should have access to the htaccess file BEFORE touching the tools that change the file.

My main concern however is as in the original post. There is no single place to find out what the current settings are and they remain active after the write to headers has been disabled because there is no delete

How many of the headers are you actually concerned with if a request goes to a non-Joomla resource on the server?

The idea came up for the content-type-options and hsts and that it is actually the server who is enforcing the rules but this header is now enforced by the default htaccess anyway.

But I agree I patch it out of the plugin in the coming days.

As suggested here hear is the PR to remove the support: #25754

Closed as having Pull Request #25754