-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
X-Content-Type headers sent twice - modHeadersAvailable not set #16938
Comments
I had this, because I had one in .htaccess and one in /etc/apache2/sites-available/host.conf |
@jookk It's a shared webhoster, so I don't have access to the apache config, but I'm pretty sure that the two places mentioned above ( |
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area. Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top. See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area. Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top. See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 Signed-off-by: zertrin <zertrin@gmail.com>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area. Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top. See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 Signed-off-by: Marc Gallet <zertrin@gmail.com>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area. Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top. See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 Signed-off-by: zertrin <zertrin@gmail.com>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area. Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top. See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 Signed-off-by: zertrin <zertrin@gmail.com>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers might be set twice (once in the default 'onsuccess' table and once in the 'always' table)! Which leads to warnings in the admin area. Adding "onsuccess unset" solves the problem, and forces the header in the 'onsucess' table to be unset, and the header in the 'always' table to be set. NOTE: with this change, Nextcloud overrides whatever the system administrator might have already set See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 and discussion in PR nextcloud#19002 Signed-off-by: zertrin <zertrin@gmail.com>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers might be set twice (once in the default 'onsuccess' table and once in the 'always' table)! Which leads to warnings in the admin area. Adding "onsuccess unset" solves the problem, and forces the header in the 'onsucess' table to be unset, and the header in the 'always' table to be set. NOTE: with this change, Nextcloud overrides whatever the system administrator might have already set See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 and discussion in PR nextcloud#19002 Signed-off-by: zertrin <zertrin@gmail.com>
Same here, Apache 2.4.38 with mod_php. In my server configuration I set nosniff and sameorigin by default in conf-enabled/security.conf. With the upgrade from Nextcloud 16 to 17 the default .htaccess-File was changed to force setting of the X- headers with the
Removing |
Another idea would be to use |
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers might be set twice (once in the default 'onsuccess' table and once in the 'always' table)! Which leads to warnings in the admin area. Adding "onsuccess unset" solves the problem, and forces the header in the 'onsucess' table to be unset, and the header in the 'always' table to be set. NOTE: with this change, Nextcloud overrides whatever the system administrator might have already set See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 and discussion in PR nextcloud#19002 Signed-off-by: zertrin <zertrin@gmail.com>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers might be set twice (once in the default 'onsuccess' table and once in the 'always' table)! Which leads to warnings in the admin area. Adding "onsuccess unset" solves the problem, and forces the header in the 'onsucess' table to be unset, and the header in the 'always' table to be set. NOTE: with this change, Nextcloud overrides whatever the system administrator might have already set See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 and discussion in PR nextcloud#19002 Signed-off-by: zertrin <zertrin@gmail.com>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers might be set twice (once in the default 'onsuccess' table and once in the 'always' table)! Which leads to warnings in the admin area. Adding "onsuccess unset" solves the problem, and forces the header in the 'onsucess' table to be unset, and the header in the 'always' table to be set. NOTE: with this change, Nextcloud overrides whatever the system administrator might have already set See github issues #16893 #16476 #16938 #18017 and discussion in PR #19002 Signed-off-by: zertrin <zertrin@gmail.com>
Copied from #8207 (comment)
I'm running NextCloud 16.0.4 on Apache/2.4.39, PHP 7.2 CGI/FastCGI. For me, the headers are sent twice - once from the
.htaccess
and once from here:server/lib/private/legacy/response.php
Lines 100 to 103 in 1b074f4
Normally, this line should avoid running into the case shown above:
server/.htaccess
Line 21 in 9d6eb2d
But the environment variable can't be retrieved by
getenv
and is not shown in a phpinfo either. Apparently, in some environments, only environment variables starting withHTTP_
can be set in the.htaccess
. I tried it and if I change the variable to e.g.HTTP_MOD_HEADERS_AVAILABLE
, it works in phpinfo as well as in theresponse.php
.Maybe someone who has more experience with Apache / PHP-CGI can tell whether this might be a solution for at least some of the issues discussed here?
Steps to reproduce
Expected behaviour
The headers like
X-Content-Type-Options: nosniff
should be transmitted exactly once. No messages warning about these headers should be displayed.modHeadersAvailable
should be set totrue
in the.htaccess
.Actual behaviour
The headers are sent twice. Once here:
server/.htaccess
Lines 16 to 21 in 9d6eb2d
and once here:
server/lib/private/legacy/response.php
Lines 100 to 103 in 1b074f4
The environment variable
modHeadersAvailable
doesn't exist.If I change the server from CGI/FastCGI to FPM, neither
modHeadersAvailable
norHTTP_MOD_HEADERS_AVAILABLE
can be accessed by PHP - they seem to be prefixed withREDIRECT_
. But FPM somehow seems to avoid sending the same headers twice, so the issue doesn't visibly appear there. However, I would not regard this as a solution to the problem, because the intended behaviour (not running into the if case if the headers have been sent by.htaccess
) doesn't apply.Server configuration
Operating system: Linux x86_64
Web server: Apache/2.4.39
Database: MySQL 5.6.19
PHP version: 7.2.11, CGI/FastCGI
Nextcloud version: 16.0.4
Updated from an older Nextcloud/ownCloud or fresh install: Continuously updated, starting from probably 11 or 12.
Where did you install Nextcloud from: https://nextcloud.com/install/#instructions-server
Signing status:
Signing status
List of activated apps:
App list
Nextcloud configuration:
Config report
Are you using external storage, if yes which one: no
Are you using encryption: no
Are you using an external user-backend, if yes which one: no
Client configuration
Browser: Mozilla Firefox 68.0.1
Operating system: Manjaro Linux
The text was updated successfully, but these errors were encountered: