I am starting to learn about http correctly.
I am working in lamp stack.
On the command line i am requesting a local page which will be served with apache to see the headers that are returned.
curl -i local.testsite
The page i am requesting has no content and i am not setting any headers but there are already a lot of headers sent in the response such as:
HTTP/1.1 200 OK
Date: Thu, 17 Jan 2013 20:28:52 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.3.10-1ubuntu3.4
Vary: Accept-Encoding
Content-Length: 0
Content-Type: text/html
So if i am not setting these, does apache set these automatically?
Yes Apache is setting those by default. By the way, if you only care about the headers, you should use
curl -I local.testsite
-I returns the headers only (HTTP HEAD request), such that even if you had content on the page you would only get the header.
Some are set by PHP:
The X-Powered-By header is set by the expose_php INI setting.
The Content-Type header is set by the default_mimetype INI setting.
The others are set by Apache:
The Server header is set by the ServerSignature directive.
The Vary: Accept-Encoding header is usually sent when mod_deflate is enabled.
Date and Content-Length are not configurable as they are part of the HTTP spec. Date is included as a MUST (except under some conditions) and Content-Length as a SHOULD.
See also How to remove date header from apache? and How to disable the Content-Length response header with Apache?.
Related
I have a website where virtual hosts are defined in /etc/apache2/sites-enabled/ with a header being set with the always option like this:
Header always set X-Frame-Options DENY
If I now set the same header using .htaccess in the web site's root folder, but without always then the header is returned twice in the server's response.
The setting in .htaccess (amongst others):
Header set X-Frame-Options DENY
The server's response:
HTTP/1.1 200 OK
Date: Mon, 02 May 2016 16:02:29 GMT
Server: Apache/2.4.10 (Debian)
X-Frame-Options: DENY
Cache-Control: no-cache, no-store, must-revalidate, private
Pragma: no-cache
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Last-Modified: Mon, 02 May 2016 15:03:42 GMT
Accept-Ranges: bytes
Content-Length: 0
X-Frame-Options: DENY
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Cache-Control: no-cache, no-store, must-revalidate, private
Pragma: no-cache
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
The Apache docs say that without the always option the default value of onsuccess is used. But they also say that "... the default value of onsuccess does not limit an action to responses with a 2xx status code..." (http://httpd.apache.org/docs/current/en/mod/mod_headers.html#header).
But if I don't add always, then error pages like 301s and 404s will not have the header set. On the other hand, if I do add always then the headers might be set twice if I do use the default value (i.e. onsuccess) in .htaccess. As the docs state: "repeating this directive with both conditions makes sense in some scenarios because always is not a superset of onsuccess with respect to existing headers". Setting headers twice is not always valid for an HTTP response, see https://stackoverflow.com/a/4371395/641481. So I want to avoid it, naturally.
My question now is: When exactly should I use onsuccess (i.e. the default value) and when always? I must admit that even after reading through the Apache docs a couple of times I do not exactly understand this. Pragmatically it seems that always using always leads to the correct/expected behaviour.
I also do not understand why Apache writes the header twice if it is set in always and onsuccess. It seems wrong to me, but there must be a good reason for this, since I assume the Apache-devs know a lot more than I do about HTTP ;-)
This is only a partial answer since it does not cover the onsuccess attribute. It is based on experiences using apache 2.4.7 running on an Ubuntu 14 os. Hope it helps you along.
The pure set parameter, without attributes, to the Header directive overwrites any always attribute by forcing the argument to Header set to be the only one delivered. If the same directive appears in a directory, i.e. file system based .htaccess file it has precedence over the same directive noted in a virtual host definition file related to that directory. If the attribute always is noted additionaly, it has the effect that any, equal or different, notation of the same directive is added to the server answer instead of overwriting/replacing it.
Probably the onsuccess attribute, which i unfortunately do not have the time to explore now, may be handled similar as the always attribute.
We use Adobe Experience Manager with a Dispatcher [caching] module for our Apache webserver. Adobe recently changed the code below. Essentially I believe you may need to use the "expr=" syntax to make sure the value is not already set. That should eliminate the duplicates.
Here's the reference code from Adobe:
Original Config: Header always append X-Frame-Options SAMEORIGIN
New Config: Header merge X-Frame-Options SAMEORIGIN "expr=%{resp:X-Frame-Options}!='SAMEORIGIN'"
When I inquired, Adobe gave me the following reasons. Thanks Adobe.
Explanation:
Using "merge" instead of "append" prevents the entry's value from from being added to the header more than once.
expr=expression: The directive is applied if and only if expression evaluates to true. Details of expression syntax and evaluation are documented in the ap_expr documentation. The "expr" is looking in the response headers from the server (Publisher Application Server) to make sure that it does not include SAMEORIGIN. This ensures that SAMEORGIN is not duplicated in the response header sent back to the request client.
It's required because testing has found that when AEM included this header Apache would duplicate the SAMEORIGIN value even with the merge option. Apache is capable of proper merge when it sources the header from itself, but because the first header was set by AEM outside of the Apache instance is when it gets weird (and requires the extra expression).
It also appears that they do not use "always" with the merge+expr syntax. Perhaps to also work around an Apache weirdness.
PS... remember to change "SAMEORIGIN" for "DENY" in your case.
I have a CloudFront distribution that blocks the font download in Chrome (desktop version) with the fallowing error:
Font from origin 'https://....cloudfront.net' has been blocked from
loading by Cross-Origin Resource Sharing policy: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'https://example.com' is therefore not allowed
access.
Where should I set this Access-Control-Allow-Origin header?
I tried adding the header in the "Origin" section of the could distribution but it does not produce any effect.
EDIT #1:
Nginx configuration on origin has the fallowing directive:
location ~ \.(eot|ttf|woff|woff2)$ {
add_header Access-Control-Allow-Origin *;
}
which on this test curl -I https://example.com/skin/frontend/smartwave/default/megamenu/css/fonts/fontawesome-webfont.woff
Retuns the fallowing response:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 02 Feb 2016 17:53:39 GMT
Content-Type: application/font-woff
Content-Length: 44432
Last-Modified: Wed, 13 May 2015 15:58:11 GMT
Connection: keep-alive
ETag: "55537493-ad90"
Pragma: public
Cache-Control: max-age=31536000, public, must-revalidate, proxy-revalidate
Accept-Ranges: bytes
From what I see here this header Access-Control-Allow-Origin is missing.
Also I whitelisted the header on CloudFront so that it will not block it:
That was hard to trace as the rules for headers were set in 2 different locations and not in one.
Fixing the correct header for the correct type of file did the job, but you have to consider the fact that in some locations trying to overwrite the NGINX rules does not work. It will only consider the first rule.
A comprehensive description of headers can be found here https://stackoverflow.com/a/10636765/1168944
I have setup apache2 with django and mod_wsgi in Debian Wheezy. I enabled mod_mem_cache with this configuration:
<IfModule mod_mem_cache.c>
CacheEnable mem /
MCacheSize 400000
MCacheMaxObjectCount 100
MCacheMinObjectSize 1
MCacheMaxObjectSize 500000
CacheIgnoreNoLastMod On
CacheIgnoreHeaders Set-Cookie
</IfModule>
based on the fact that MCacheMaxStreamingBuffer is the smaller of 100000 or MCacheMaxObjectSize as stated in the docs.
When I try hitting a page with size 3.3KB I get these response headers in firebug:
Connection Keep-Alive
Content-Encoding gzip
Content-Type text/html; charset=utf-8
Date Wed, 27 Aug 2014 14:47:39 GMT
Keep-Alive timeout=5, max=100
Server Apache/2.2.22 (Debian)
Transfer-Encoding chunked
Vary Cookie,Accept-Encoding
and the page isn't served from cache. In the page source there is however the correct header 'Cache-Control: max-age=300,must-revalidate' but doesn't show up in firebug.
In apache log I only see correctly:
[info] mem_cache: Cached url: https://83.212.**.**/?
With another test page that I created outside of django that doesn't have chunked encoding as a header, caching works fine. Why is the page not served from cache? Has anyone seen something similar?
I'm using LAMP (Linux, Apache, MySQL, PHP) server.
Currently the server sends the response with next Headers list. I want to eliminate Keep-Alive entry for security reasons, to have Headers list without it. Is it possible to prevent sending the Keep-Alive entry in the Headers list?
Current Response Headers:
Cache-Control private, no-cache, no-store, must-revalidate, post-check=0, pre-check=0
Connection Keep-Alive
Content-Encoding gzip
Content-Type text/html; charset=UTF-8
Date Thu, 13 Mar 2014 01:43:49 GMT
Expires Thu, 13 Mar 2014 01:43:49 GMT
Keep-Alive timeout=5, max=200
Last-Modified Thu, 13 Mar 2014 01:43:49 GMT
Pragma no-cache
Server Apache
Transfer-Encoding chunked
Vary Accept-Encoding
X-DNS-Prefetch-Control off
X-Frame-Options sameorigin
Response Headers I Would Like Instead:
Cache-Control private, no-cache, no-store, must-revalidate, post-check=0, pre-check=0
Connection Keep-Alive
Content-Encoding gzip
Content-Type text/html; charset=UTF-8
Date Thu, 13 Mar 2014 01:43:49 GMT
Expires Thu, 13 Mar 2014 01:43:49 GMT
Last-Modified Thu, 13 Mar 2014 01:43:49 GMT
Pragma no-cache
Server Apache
Transfer-Encoding chunked
Vary Accept-Encoding
X-DNS-Prefetch-Control off
X-Frame-Options sameorigin
Is it possible to prevent sending the Keep-Alive entry in the Headers list?
To my knowledge, no. The whole purpose of the Keep-Alive header is to communicate the need for a persistent connection to the client. So getting rid of the headers gets rid of the main form of communication between the client & the server.
That said, you might be able to get it unset by using unset in your Apache config or .htaccess as explained here. I emphasize might since I have had header directives not behave as expected in some versions of Apache. But assuming good faith, first be sure the headers module is enabled. In Ubuntu 12.04 you would do this:
sudo a2enmod headers
And then add this to your Apache config or .htaccess:
<IfModule mod_headers.c>
Header unset Keep-Alive
</IfModule>
Now restart Apache:
sudo service apache2 restart
More details on the header directive are here.
There are a few ways to this in apache:
Server-wide using the KeepAlive directive ( KeepAlive ). However you can not have this in per-directory configuration files, so setting KeepAlive Off will turn off keep alive for the entire server.
Using SetEnv or SetEnvIf with mod_env, and set the nokeepalive environmental variable. This will turn off keepalive for the location where the environmental is set, or the rule that is matched by SetEnvIf (depending with you use). e.g.
can be in HTACCESS
SetEnv nokeepalive 1
Using mod_rewrite to again set the environmental for a specific rule, e.g.
RewriteRule some-file.html - [E=nokeepalive:1]
Using PHP (or any other server site language) and sending the header Connection: close. This will cause Apache to omit the Keep-Alive header, since the connection is no longer keepalive. e.g.
php
header('Connection: close');
Use mod_headers to set the connection header to close again, e.g.
Header set Connection "close"
I personally have not tested the last one, but it should work.
KeepAlive behavior (availability and timeouts) is directly configurable:
http://httpd.apache.org/docs/2.4/mod/core.html#keepalive
Changing this is primarily an aspect of performance rather than security, but you're free to test the implications in your own environment.
I had my site tested with the Page Speed app from Google and one of the suggestions was to specify the character set in the HTTP Content-Type response header claiming it was better than just in a meta tag.
Here's what I understand I need to write:
Content-Type: text/html; charset=UTF-8
..but where exactly should I put this? I'm on a shared server.
Thank you!
Apache: add to your .htaccess file in root directory:
AddDefaultCharset UTF-8
It will modify the header from this:
Content-Type text/html
...to this:
Content-Type text/html; charset=UTF-8
nginx [doc] [serverfault Q]
server {
# other server config...
charset utf-8;
}
add charset utf-8; to server block (and reload nginx config)
When i added this, my response header looked like this:
HTTP/1.1 200 OK
Content-Type: text/html,text/html;charset='UTF-8'
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
With Apache, you use http://httpd.apache.org/docs/2.2/mod/core.html#adddefaultcharset
With IIS you edit the MIME type for the filetype in the list of files.
With most server-side technologies like PHP or ASP.NET there's a method or property provided by that technology. For example in ASP.NET you can set it in config, page, or page code-behind.