For security reason, i need remove(yes!, really I need remove, delete or hide) Apache signature.
I use ServerSignature n' ServerTokens directives, but only hide the version...
ServerSignature Off
ServerTokens Prod
The results is:
Name :Value
Date :Mon, 15 Jun 2015 11:47:28 GMT
Content-Encoding :gzip
Last-Modified :Sun, 14 Jun 2015 00:01:37 GMT
Server :Apache
ETag :"6176c-28f4-5186f0b8c3bb0"
Vary :Accept-Encoding,User-Agent
Content-Type :text/xml; charset=utf-8
Cache-Control :max-age=1
Accept-Ranges :bytes
Content-Length :1531
Expires :Mon, 15 Jun 2015 11:47:29 GMT
Look this
Server Apache
I need(without http header "Server:Apache"):
Name Value
Date Mon, 15 Jun 2015 11:47:28 GMT
Content-Encoding gzip
Last-Modified Sun, 14 Jun 2015 00:01:37 GMT
ETag "6176c-28f4-5186f0b8c3bb0"
Vary Accept-Encoding,User-Agent
Content-Type text/xml; charset=utf-8
Cache-Control max-age=1
Accept-Ranges bytes
Content-Length 1531
Expires Mon, 15 Jun 2015 11:47:29 GMT
Thanks!
I am very sorry Apache team, but this time can't show your
signature.
The core distribution doesn't allow it to be removed. It's trivial to do in a plugin. mod_security allows you to configure it to be stripped.
This should be a comment, but it's a bit long....
For security reason, i need remove...Apache signature - even from the data other than the Server header it is blatantly obvious that this is an Apache server (or something doing a very good impression of one).
As per discussion on security.stackexchange I do not believe that there is any security benefit in removing banners from your software. In addition to the information in your headers I could also determine this from the default error messages, how the server handles content negotiation, conditional requests, .... every time I look at a related issue, the list gets longer.
I've yet to see any evidence that disabling banners had any impact on a sites security (as opposed to allowing an auditor to tick a box in a checklist). But if anyone can provide a reference I would be very interested to hear.
Related
I would like to serve some Unreal-generated HTML5 files using Google Cloud storage. Some of the files are gzip-encoded, and one of the javascript files checks that every file which ends with gz is returned with Content-Encoding: gzip. I don't want to change these files.
In GC UI, I set the Content-Encoding (and Content-type) fields in file metadata. To prevent decompressive transcoding I also set Cache-Control: no-transform. Despite that, the Content-Encoding header is still missing. (full header below). Is there anything else I can do to make Google Cloud respond with Content-Encoding?
HTTP/1.0 200 OK
X-GUploader-UploadID: some hash
Date: Sun, 24 Feb 2019 01:06:05 GMT
Cache-Control: no-transform
Expires: Mon, 24 Feb 2020 01:06:05 GMT
Last-Modified: Sun, 24 Feb 2019 00:52:29 GMT
x-goog-generation: 1550969549021835
x-goog-metageneration: 3
x-goog-stored-content-encoding: gzip
x-goog-stored-content-length: 99750206
Content-Type: application/octet-stream
x-goog-hash: crc32c=oobjmg==
x-goog-hash: md5=fN6srk43sVaYDVNgpXtdLQ==
x-goog-storage-class: REGIONAL
Accept-Ranges: none
Server: UploadServer
Vary: Accept-Encoding
This below is the HTTP header of my site. I need to know:
what is Cache-Control: max-age=259200?
Do you think that a so high value 259200 would prevent Googlebot to index my pages? Should I lower that value?
We talk about a blog of information, publishing articles every day.
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 25 Feb 2017 15:07:53 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 123783
Connection: keep-alive
X-Powered-By: PHP/7.0.14
X-Pingback: http://www.example.com/xmlrpc.php
Link: <http://www.example.com/wp-json/>; rel="https://api.w.org/", <http://www.example.com/?p=1427>; rel=shortlink
Vary: Accept-Encoding
X-Powered-By: PleskLin
Cache-Control: max-age=259200
Expires: Tue, 28 Feb 2017 15:07:52 GMT
According to https://developer.mozilla.org/ru/docs/Web/HTTP/Headers/Cache-Control
max-age=<seconds>
Specifies the maximum amount of time a resource will be considered fresh. Contrary to Expires, this directive is relative to the time of the request.
In other words this is time interval for which any client such as browser or proxy server might use cached version.
How exactly it affects google I'm not sure. Googlebot might take it into account in some way (but I doubt they blindly trust you). This might be an issue if you have it on your main page because the bot might not come back for 3 days (259200 seconds = 3 days) to see new articles/posts. The same goes for new comments. Still if google ignores your site for much longer than that, the issue is not with caching but somewhere else.
You might also consider looking into Google Webmaster Tools. Start at https://support.google.com/webmasters/answer/34397/?hl=en and https://support.google.com/webmasters/answer/6065812/?hl=en
I've put this in my head section. It appears in the page source in the browser.
<meta http-equiv="Cache-Control" content="max-age=1209600">
However, when I look in the Chrome extension Live HTTP Headers, it says the following.
Cache-Control: max-age=0
Content-Encoding: gzip
Content-Length: 5849
Content-Type: text/html; charset=utf-8
Date: Sat, 05 Apr 2014 04:29:16 GMT
Expires: Sat, 05 Apr 2014 04:29:16 GMT
Last-Modified: Sat, 05 Apr 2014 03:33:19 GMT
The max-age isn't registering. I've emptied the browser cache but it makes no difference.
Any explanations? This is the site, incidentally.
UPDATES:
Firebug similarly records Cache-Control: max-age=0.
Google also makes clear here that max-age overrides the Expires header (which I don't set) and that you don't need both.
When you use tools like Live HTTP Headers, they show you the actual HTTP headers sent by the browser. What they do with meta tags used to simulate HTTP headers is a different issue. We can expect any conflict to be resolved in favor of the actual headers. (This has been normatively specified in HTML specs for Content-Type headers.)
To control cacheing, you should (at least primarily) use server configuration. See Caching Tutorial for Web Authors and Webmasters.
I noticed that chrome cached a video file. I replaced it with another one on the server and chrome kept serving the old one from cache (using JW flash player 5)
The headers of the request look like this:
joe#joe-desktop:~$ wget -O - -S --spider http://www.2xfun.de/files_geheimhihi14/20759.mp4
Spider mode enabled. Check if remote file exists.
--2011-05-15 22:40:56-- http://www.2xfun.de/files_geheimhihi14/20759.mp4
Resolving www.2xfun.de... 213.239.214.112
Connecting to www.2xfun.de|213.239.214.112|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Sun, 15 May 2011 20:40:56 GMT
Server: Apache
Last-Modified: Sun, 15 May 2011 20:37:59 GMT
ETag: "89b38-3bb227-4a35683b477c0"
Accept-Ranges: bytes
Content-Length: 3912231
Cache-Control: max-age=29030400, public, must-revalidate
Expires: Sun, 15 Apr 2012 20:40:56 GMT
Connection: close
Content-Type: video/mp4
Length: 3912231 (3.7M) [video/mp4]
Remote file exists.
I am using mod_headers and mod_expires in apache2 like this:
<FilesMatch "\.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav|mp4)$">
ExpiresDefault A29030400
Header append Cache-Control "public, must-revalidate"
</FilesMatch>
Did I spell revalidate wrong or something?
edit:
To make the use case clear: I want the files to be cached, because they are rather big and I want to save bandwidth. But on the other hand I want the files to be re-validated. So the client does a HEAD request and checks whether the content has changed (thats what the etag is for), and only re-fetches if necessary.
Your problem is that must-revalidate only kicks in once a cache entry is no longer fresh, but you've marked the response as cacheable for 29 million seconds. 'Cache-Control: max-age=0, must-revalidate' may be closer to what you want, if you want to allow caching but require revalidation on each use.
I'm having a problem where items served by my Squid server are being cached by Limelight for too long, sometimes days. It happens when a piece of content has been static for a long time (weeks) and then undergoes numerous changes in a matter of hours.
Limelight gets its content from our Squid server and I'm told that if I can add 'Expires: 15m' in the HTTP header the Squid server sends, Limelight will not cache the image for more than 15 min.
Unfortunately, I can fond no setting in Squid that will allow me to add this to the header.
Here's the HTTP header as presently being sent:
HTTP/1.0 200 OK
Date: Tue, 15 Dec 2009 23:57:33 GMT
Server: nginx/0.5.26
Content-Type: image/jpeg
Content-Length: 83843
Last-Modified: Tue, 15 Dec 2009 23:52:00 GMT
Accept-Ranges: bytes
Age: 450
X-Cache: HIT from squid01.prod.mydomain
X-Cache-Lookup: HIT from squid01.prod.mydomain:3128
Via: 1.0 squid01.prod.mydomain:3128 (squid/2.6.STABLE14)
Connection: close
You need to set the header on the origin server, not on your Squid box.
See:
http://www.mnot.net/cache_docs/#IMP-SERVER