I'm building a webpage and I'm getting the following warning (and the page loads but when I change of section it never loads and displays the warning).
The warning:
HTTP/1.1 200 OK Cache-Control:
no-store, no-cache, must-revalidate,
post-check=0, pre-check=0 Pragma:
no-cache Content-Type: text/html
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET Date: Wed, 10
Mar 2010 12:04:11 GMT Content-Length:
4022
I think it didn't happen in my computer at home. The problem seems to happen just few times (apparently random). I'm using cookies and sessions (php) in this web page.
This is getting very strange, I just came back to my house and the problem disappeared (it was because in the another computer I was using Vista?).
Is this a problem with the webpage or the server?
It seems everything normal here.
So, Do you have proxy in that environment? In very rare case, some proxy could cause that issue.
Related
I have to, sadly, poll an endpoint and update another system when the data changes. I wrote a loop (with a sleep statement so I don’t DOS the server):
require 'nokogiri'
require 'open-uri'
desired_data = 'foo'
data = nil
url = nil
while data != desired_data do
sleep(2)
url = "https://elections.wi.gov/index.php/elections-voting/statistics"
doc = Nokogiri::HTML.parse(open(url))
puts doc
# do some nokogiri stuff to extract the information I want.
# store information to `data` variable.
end
# if control is here it means the data changed
This works fine except when the server updates, open(url) still returns the old content (even if I restart the script).
It seems like there may be some caching at play. How do I disable it?
Here are the HTTP headers returned:
HTTP/2 200
date: Fri, 02 Oct 2020 14:00:44 GMT
content-type: text/html; charset=UTF-8
set-cookie: __cfduid=dd8fca84d468814dd199dfc08d45c98831601647244; expires=Sun, 01-Nov-20 14:00:44 GMT; path=/; domain=.elections.wi.gov; HttpOnly; SameSite=Lax; Secure
x-powered-by: PHP/7.2.24
cache-control: max-age=3600, public
x-drupal-dynamic-cache: MISS
link: <https://elections.wi.gov/index.php/elections-voting/statistics>; rel="canonical"
x-ua-compatible: IE=edge
content-language: en
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
expires: Sun, 19 Nov 1978 05:00:00 GMT
last-modified: Fri, 02 Oct 2020 12:47:38 GMT
vary: Cookie
x-generator: Drupal 8 (https://www.drupal.org)
x-drupal-cache: HIT
x-speed-cache: HIT
x-speed-cache-key: /index.php/elections-voting/statistics
x-nocache: Cache
x-this-proto: https
x-server-name: elections.wi.gov
access-control-allow-origin: *
x-xss-protection: 1; mode=block
cache-control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
cf-cache-status: DYNAMIC
cf-request-id: 058b368b9f00002ff234177200000001
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 5dbef38c3b6a2ff2-ORD```
If it matters, I’m using Ruby 2.7 on macOS Big Sur.
It might be a problem on the Drupal 8 website itself as it has its own cache manager - and it seems like there's a cache per user somewhere if you have new content using a web browser.
It is easy to see which cache contexts a certain page varies by and which cache tags it is invalidated by: one must only look at the X-Drupal-Cache-Contexts and X-Drupal-Cache-Tags headers!
But those headers are not available in your list. If you're in touch with the website's developers ask them to do the following:
You can debug cacheable responses (responses that implement this interface, which may be cached by Page Cache or Dynamic Page Cache) by setting the http.response.debug_cacheability_headers container parameter to true, in your services.yml. Followed by a container rebuild, which is necessary when changing a container parameter.
That will cause Drupal to send X-Drupal-Cache-Tags, X-Drupal-Cache-Contexts headers.
I am working on a web application which has user management in place. I find a concerning issue in firefox related to Work Offline. Following are the steps describing the scenario:
User logs in to the application
User performs some action and logs out of the application
If the user now enables Work Offline mode in firefox, he/she can use browser back to access the last page. However, this page is supposed to be secure.
In my opinion this is a data security issue as any other user can apply this technique to fetch valuable information of the last user.
I have used cache control headers to communicate to the browser that HTML content should not be cached. Following are the response headers used:
HTTP/1.1 200 OK
Date: Tue, 05 May 2015 10:39:30 GMT
Server: Apache/2.4.9 (Unix) OpenSSL/0.9.8za
Cache-Control: no-cache, no-store
Expires: Wed, 31 Dec 1969 23:59:59 GMT
Content-Type: text/html;charset=UTF-8
Content-Language: en
Vary: Accept-Encoding
Content-Encoding: gzip
X-Frame-Options: SAMEORIGIN
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
I have used
Cache-Control: no-cache, no-store
Expires: Wed, 31 Dec 1969 23:59:59 GMT
I have noted this vulnerability in applications like Facebook. Is this resolvable? Thank you.
In my MVC3 project I have the following class-level attributes set on some of my controllers:
[OutputCache(Location = System.Web.UI.OutputCacheLocation.Server, Duration = 14400, VaryByParam = "*")]
Duration = four hours.
I used VaryByParam = "*" as there are differing parameters for the controller's action methods, instead of VaryByParam = "none" - Is this the correct use?
In IIS, on the server level and in all the web.config files for my sites, I set the static caching to eight days.
Observing the headers in Fiddler, when I go to a search result page, I see the following:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Expires: -1
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 3.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Thu, 15 Aug 2013 17:21:32 GMT
Content-Length: 148842
For my site scripts js files:
HTTP/1.1 200 OK
Cache-Control: max-age=691200
Content-Type: application/x-javascript
Last-Modified: Thu, 15 Aug 2013 05:35:35 GMT
Accept-Ranges: bytes
ETag: "10906a447999ce1:0"
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Thu, 15 Aug 2013 17:21:32 GMT
Content-Length: 2999
And for css:
HTTP/1.1 304 Not Modified
Cache-Control: max-age=691200
Last-Modified: Wed, 07 Aug 2013 21:31:28 GMT
Accept-Ranges: bytes
ETag: "f08ce079b593ce1:0"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Thu, 15 Aug 2013 17:21:33 GMT
Using Google's PageSpeed affiliate (http://www.webpagetest.org/) I was able to get up to around 90/100 on my pages - page load time is about 4 seconds, the report shows .47s optimized - see the confusing results here . When I playback the video on WebPageTest of Original vs. Optimized, my original finishes in 2.5s (and has a lower speed index) and optimized in 4.7s.
Google's PageSpeed Insights suggests to optimize CSS delivery. I am already serving up CSS asynchronously.
As I am hosting on AWS, I cranked up the juice on the instance to one of their most powerful server instances. Page load times were about the same as my regular instance.
So I am confused by the first result up top: Cache-Control: no-cache . Have I not implemented caching correctly, and if not, what am I missing?
Good Day.
I'm trying to figure out a caching issue. We are currently using a CMS with built in caching. We can then delete the cached copy via the control panel and the uncached page will be served until we cache that page again.
Long story short, we know that a either a proxy server or load balancer was put in place, and we think that it is caching the pages as well as the CMS. Our specific issue is that when we un-cache the page in the CMS, it's taking 15 minutes (timed) to show up un-cached (even after using different browser, clearing the browser cache, etc.), when prior to the network appliance being introduced, the un-cached page would show up immediately. Unfortunately we don't have any historical response headers saved anywhere.
When we believe that the page is being cached by the proxy/lb, the Response header is returning:
HTTP/1.1 304 Not Modified
Server: Apache/2.0.59 (Unix) JRun/4.0 mod_ssl/2.0.59 OpenSSL/0.9.8k PHP/5.2.6
Last-Modified: Fri, 03 Aug 2012 13:29:12 GMT
Etag: "92fe-18f7-837ada00"
Accept-Ranges: bytes
Keep-Alive: timeout=5, max=100
Content-Type: text/html
Content-Encoding: gzip
Connection: Keep-Alive
Date: Mon, 06 Aug 2012 13:49:40 GMT
X-Cntnt-Length: 6391
When it's not being cached by the CMS, the response headers are:
HTTP/1.0 200 OK
Date: Mon, 06 Aug 2012 14:03:59 GMT
Server: Apache/2.0.59 (Unix) JRun/4.0 mod_ssl/2.0.59 OpenSSL/0.9.8k PHP/5.2.6
X-Powered-By: PHP/5.2.6
Set-Cookie: blah-blah-blah
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Mon, 06 Aug 2012 14:04:04 GMT
Pragma: no-cache
Connection: close
Content-Type: text/html
I guess my question is, can Apache2 be configured to return both HTTP 1.0 and 1.1 ?
I know the Etag indicates a cached page, and believe it's not available in HTTP/1.0.
Thanks for any insights.
We're having some really strange problems with IE7, and only IE7. When trying to replicate the issue it only happens with native IE7, not when running IE7 mode in IE8/9, so please remember that if you try to replicate this issue.
The problem is the following:
We're polling for a response from the server with AJAX. The user posts something that the server may have to work on for a bit, so every 5 seconds or so a request is sent check if the server is done. This works fine in every browser, except native IE7. The problem is that it never stops "loading". When checking the requests with Fiddler2 we see that it does two requests and then nothing more. It stops doing anything when still in PENDING mode. In a sain browser it keeps on polling, and then stops when it gets "CONFIRMED". The really weird thing is that it does its final request and returns as normal, only, and really only, when you open a new tab.
It's not that the page needs focus or anything, clicking around randomly does nothing. I'm asking here because I can't even reproduce the issue using a local instance of the project.
Here are the headers sent back by the server:
These are the headers for the response on the production machine. This was the last response gotten. It loads indefinitely until you open a new tab (just an empty new tab!), then the final request is made and everything works out.
HTTP/1.1 200 OK
Accept-Ranges: bytes
Age: 0
Cache-Control: max-age=0, private, must-revalidate
Content-Type: application/json; charset=utf-8
Date: Tue, 04 Oct 2011 07:37:45 GMT
ETag: "867dafc628c43b6ca8a73d1977669250"
P3P: CP="ALL DSP COR CURa ADMa DEVa OUR IND COM NAV"
Server: nginx/1.0.6
Set-Cookie: _web_session=COOKIE; path=/; expires=Tue, 04-Oct-2011 10:37:45 GMT; HttpOnly
Vary: Accept-Encoding
Via: 1.1 varnish
X-Cache: MISS
X-Runtime: 0.062794
X-UA-Compatible: IE=Edge,chrome=1
X-Varnish: 55900984
Content-Length: 145
Connection: keep-alive
{"direct_publishing_settings_id":9970,"confirmed":"PENDING","errors":{},"username":"************","url":"","blog_id":44606,"platform":"blogg_se"}
These are the headers for the same request on my local server. This does not stall up the requests.
HTTP/1.1 200 OK
X-Ua-Compatible: IE=Edge
Etag: "253c934246a69c9ca821464f80f400b3"
P3p: CP="ALL DSP COR CURa ADMa DEVa OUR IND COM NAV"
Connection: Keep-Alive
Content-Type: application/json; charset=utf-8
Date: Tue, 04 Oct 2011 07:34:22 GMT
Server: WEBrick/1.3.1 (Ruby/1.8.7/2010-01-10)
X-Runtime: 0.459232
Content-Length: 137
Cache-Control: max-age=0, private, must-revalidate
Set-Cookie: _web_session=COOKIE; path=/; expires=Tue, 04-Oct-2011 10:34:22 GMT; HttpOnly
{"direct_publishing_settings_id":10,"confirmed":"PENDING","url":"","blog_id":29,"errors":{},"username":"fsasaffas","platform":"blogg_se"}
If you want to try it you can go to videofy.me, get a new account (it's really easy), when logged in go to videofy.me/blogger/settings/direct_publishing. Choose a blog platform in the first dropdown, press "activate" and write something into the username/password fields that appear, then press the green button and wait forever. After 45 seconds or a random amount of time open a new tab, and see that the request is magically finished.
I'm guessing it has to do something with IE7 cacheing the request, and then something is released if a new tab is opened. But it's just a guess, and googling returns nothing related. I'm posting here because it's so obscure that I hope someone here knows anything about it.