I'm using internet explorer 11 with windows 10.
As a way to expire cookies, I have set the 'expires=' to a point in the past.
When I tested
The following formats are not supported. (Cookie was not removed.)
Set-Cookie: expires=Wed, 01-Jan-70 00:00:00 GMT
However, the following formats are supported. (Cookie was removed.)
Set-Cookie: expires=Wed, 01 Jan 1970 00:00:00 GMT
I confirmed that the former was rfc850 and the latter was rfc1123.
I wonder if there is an official document or reference for this result.
You could check from the MDN docs that the detailed format is:
Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
Reference:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie
Expires= Optional
The maximum lifetime of the cookie as an HTTP-date timestamp. See Date for the detailed format. If not specified, the cookie will have the lifetime of a session cookie. A session is finished when the client is shut down meaning that session cookies will get removed at that point.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date
The Date general HTTP header contains the date and time at which the message was originated.
Related
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'm reading it in Webpack docs:
The way it works has a pitfall: if we don’t change filenames of our resources when deploying a new version, browser might think it hasn’t been updated and client will get a cached version of it.
I'm curious, is it mandatory to use this mechanism with ugly file names main.55e783391098c2496a8f.js for assets in order to inform a browser that an asset file has changed?
Can it be controlled by HTTP headers only? There are multiple HTTP headers in the standard to control how browser caches assets, like:
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Date: Wed, 24 Aug 2020 18:32:02 GMT
Last-Modified: Tue, 15 Nov 2024 12:45:26 GMT
ETag: x234dff
max-age: 12345
So can I use those headers alone? Or do I still have to bother about hash parts in file names main.55e783391098c2496a8f.js?
When user agent opens a page it must always get correct version of a source code. You have two options to achieve this:
Set Cache-Control, Expires and strong validator (ETag) response headers . This way you instruct user agent to perform relatively lightweight conditional request on each page load
Embed version in source code file URL and set Cache-Control and Expires response headers. This way you instruct user agent to cache source code with particural version forever
For more information check HTTP Caching article by Ilya Grigorik, HTTP conditional requests MDN page and this StackOverflow answer about resource revalidation.
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.
We are deprecating the REST service and we want to inform the client about this. what is the best practice followed?
I can think of following options
Pass the deprecation warning message as part of service response JSON/XML
Pass the warning message in HTTP “Warning” Response header.
Could you please share your ideas?
I would not change anything in the status code or in the service response to be backward compatible. I would add a "Warning" header in the response.
Warning: 299 - "Deprecated API"
You could also check this (old) response: https://softwareengineering.stackexchange.com/questions/55081/deprecate-a-web-api-best-practices
There is an IETF draft "The Deprecation HTTP Header Field" which recommends adding special HTTP-headers to server response.
Examples
The first example shows a deprecation header field without date information:
Deprecation: true
The second example shows a deprecation header with date information and a link to the successor version:
Deprecation: Sun, 11 Nov 2018 23:59:59 GMT
Link: <https://api.example.com/v2/customers>; rel="successor-version"
The third example shows a deprecation header field with links for the successor version and for the API’s deprecation policy. In addition, it shows the sunset date for the deprecated resource:
Deprecation: Sun, 11 Nov 2018 23:59:59 GMT
Sunset: Wed, 11 Nov 2020 23:59:59 GMT
Link: <https://api.example.com/v2/customers>; rel="successor-version", <https://developer.example.com/deprecation>; rel="deprecation"
In Apache's mod_expires module, there is the Expires directive with two base time periods, access, and modification.
ExpiresByType text/html "access plus 30 days"
understandably means that the cache will request for fresh content after 30 days.
However,
ExpiresByType text/html "modification plus 2 hours"
doesn't make intuitive sense.
How does the browser cache know that the file has been modified unless it makes a request to the server? And if it is making a call to the server, what is the use of caching this directive? It seems to me that I am not understanding some crucial part of caching. Please enlighten me.
An Expires* directive with "modification" as its base refers to the modification time of the file on the server. So if you set, say, "modification plus 2 hours", any browser that requests content within 2 hours after the file is modified (on the server) will cache that content until 2 hours after the file's modification time. And the browser knows when that time is because the server sends an Expires header with the proper expiration time.
Let me explain with an example: say your Apache configuration includes the line
ExpiresDefault modification plus 2 hours
and you have a file index.html, which the ExpiresDefault directive applies to, on the server. Suppose you upload a version of index.html at 9:53 GMT, overwriting the previous existing index.html (if there was one). So now the modification time of index.html is 9:53 GMT. If you were running ls -l on the server (or dir on Windows), you would see it in the listing:
-rw-r--r-- 1 apache apache 4096 Feb 18 09:53 index.html
Now, with every request, Apache sends the Last-Modified header with the last modification time of the file. Since you have that ExpiresDefault directive, it will also send the Expires header with a time equal to the modification time of the file (9:53) plus two hours. So here is part of what the browser sees:
Last-Modified: Wed, 18 Feb 2009 09:53:00 GMT
Expires: Wed, 18 Feb 2009 11:53:00 GMT
If the time at which the browser makes this request is before 11:53 GMT, the browser will cache the page, because it has not yet expired. So if the user first visits the page at 11:00 GMT, and then goes to the same page again at 11:30 GMT, the browser will see that its cached version is still valid and will not (or rather, is allowed not to) make a new HTTP request.
If the user goes to the page a third time at 12:00 GMT, the browser sees that its cached version has now expired (it's after 11:53) so it attempts to validate the page, sending a request to the server with a If-Modified-Since header. A 304 (not modified) response with no body will be returned since the page's date has not been altered since it was first served. Since the expiry date has passed -- the page is 'stale' -- a validation request will be made every subsequent time the page is visited until validation fails.
Now, let's pretend instead that you uploaded a new version of the page at 11:57. In this case, the browser's attempt to validate the old version of the page at 12:00 fails and it receives in the response, along with the new page, these two new headers:
Last-Modified: Wed, 18 Feb 2009 11:57:00 GMT
Expires: Wed, 18 Feb 2009 13:57:00 GMT
(The last modification time of the file becomes 11:57 upon upload of the new version, and Apache calculates the expiration time as 11:57 + 2:00 = 13:57 GMT.)
Validation (using the more recent date) will not be required now until 13:57.
(Note of course that many other things are sent along with the two headers I listed above, I just trimmed out all the rest for simplicity)
The server sends a header such as: "Last-Modified: Wed, 18 Feb 2009 00:00:00 GMT". The cache behaves based on either this header or the access time.
Say if the content is expected to be refreshed every day, then you want it to expire "modification plus 24 hours".
If you don't know when the content will be refreshed, then it's better to base it on the access time.
My understanding is that modification asks the browser to base the cache time based on the Last-Modificatied HTTP header's value. So, modification plus 2 hours would be the Last-Modificatied time + 2 hours.
First of all, thanks to David Z for the detailed explanation above. In answer to bushman's question about why does it make sense to invoke caching if the server is still required to make a request, the answer is that the time is saved in what is returned by the server. If the cache directives indicate that a file's content is still fresh, instead of returning content, a 304 code is returned with an empty response body. That is where the time is saved.
A better explanation than I've given is here, from https://devcenter.heroku.com/articles/increasing-application-performance-with-http-cache-headers :
Though conditional requests do invoke a call across the network, unmodified resources result in an empty response body – saving the cost of transferring the resource back to the end client. The backend service is also often able to very quickly determine a resource’s last modified date without accessing the resource which itself saves non-trivial processing time.
Time-based
A time-based conditional request ensures that only if the requested resource has changed since the browser’s copy was cached will the contents be transferred. If the cached copy is the most up-to-date then the server returns the 304 response code.
To enable conditional requests the application specifies the last modified time of a resource via the Last-Modified response header.
Cache-Control:public, max-age=31536000
Last-Modified: Mon, 03 Jan 2011 17:45:57 GMT
The next time the browser requests this resource it will only ask for the contents of the resource if they’re unchanged since this date using the If-Modified-Since request header
If-Modified-Since: Mon, 03 Jan 2011 17:45:57 GMT
If the resource hasn’t changed since Mon, 03 Jan 2011 17:45:57 GMT the server will return with an empty body with the 304 response code.