I am trying to prevent If-modified request from client to server but I am failing.
I think that I am missing something so I am attaching the HTTP communication of the two requests. I would expect that the second request will not be issued:
GET XXXXX/js/Is.js HTTP/1.1
Accept: */*
Referer: http://XXXXX/XXXXX/
Accept-Language: he
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Hewlett-Packard; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: xxxxxxxx:8080
Connection: Keep-Alive
Pragma: no-cache
Cookie: JSESSIONID=XXXXXX
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: public,max-age=860000
Expires: Sun, 3 Jan 2010 00:00:00 GMT
ETAG: W/"1634-1260925588406"
Last-Modified: Wed, 16 Dec 2009 01:06:28 GMT
Content-Encoding: gzip
Content-Type: text/javascript
Content-Length: 412
Date: Sun, 27 Dec 2009 07:25:52 GMT
GET /XXXXXXXX/Is.js HTTP/1.1
Accept: */*
Referer: http://XXXXXXXXX/XXXXXXX/servlet/Main
Accept-Language: he
UA-CPU: x86
Accept-Encoding: gzip, deflate
If-Modified-Since: Wed, 16 Dec 2009 01:06:28 GMT
If-None-Match: W/"1634-1260925588406"
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Hewlett-Packard; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: xxxxxx:8080
Connection: Keep-Alive
Pragma: no-cache
Cookie: JSESSIONID=XXXXXX;
HTTP/1.1 304 Not Modified
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: public,max-age=860000
Expires: Sun, 3 Jan 2010 00:00:00 GMT
ETAG: W/"1634-1260925588406"
Date: Sun, 27 Dec 2009 07:34:33 GMT
The Pragma: no-cache in the second request indicates that it happened as a result of a page refresh. A 304 is a correct response in that case. If you want to force a re-read, then you should use control-refresh.
You're sending Pragma: No-cache in your first response. That prevents Firefox from caching.
I think that I have found the problem.... I knew that I was missing something
The first document loaded is doing redirect with :
<meta HTTP-EQUIV="Refresh" CONTENT="1; URL=/XXXXX">
Thanks for all your help ....
Related
I've been working on this issue for two days. If I create a new project following the tutorial here, and run it through IIS Express, it works fine. As soon as I switch it to IIS, it fails.
So, when hosted in Express I send:
OPTIONS http://localhost:63274/api/test HTTP/1.1
Host: localhost:63274
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Access-Control-Request-Method: PUT
Origin: http://localhost:4001
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36
DNT: 1
Accept: */*
Referer: http://localhost:4001/admin/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-CA,en;q=0.9,fr;q=0.8
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Server: Microsoft-IIS/10.0
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: PUT
X-SourceFiles: =?UTF-8?B?RDpcSGVicmFcTWluZGZsYXllclxNaW5kZmxheWVyXGFwaVx0ZXN0?=
X-Powered-By: ASP.NET
Date: Wed, 24 Jul 2019 15:45:48 GMT
Content-Length: 0
And after the preflight:
PUT http://localhost:63274/api/test HTTP/1.1
Host: localhost:63274
Connection: keep-alive
Content-Length: 0
Pragma: no-cache
Cache-Control: no-cache
Origin: http://localhost:4001
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36
DNT: 1
Accept: */*
Referer: http://localhost:4001/admin/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-CA,en;q=0.9,fr;q=0.8
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 17
Content-Type: text/plain; charset=utf-8
Expires: -1
Server: Microsoft-IIS/10.0
Access-Control-Allow-Origin: *
X-SourceFiles: =?UTF-8?B?RDpcSGVicmFcTWluZGZsYXllclxNaW5kZmxheWVyXGFwaVx0ZXN0?=
X-Powered-By: ASP.NET
Date: Wed, 24 Jul 2019 15:45:48 GMT
PUT: Test message
And when hosted from IIS I send (an identical request of):
OPTIONS http://localhost:4013/api/test HTTP/1.1
Host: localhost:4013
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Access-Control-Request-Method: PUT
Origin: http://localhost:4001
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36
DNT: 1
Accept: */*
Referer: http://localhost:4001/admin/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-CA,en;q=0.9,fr;q=0.8
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Server: Microsoft-IIS/10.0
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: PUT
Date: Wed, 24 Jul 2019 15:50:34 GMT
Content-Length: 0
And after the preflight:
PUT http://localhost:4013/api/test HTTP/1.1
Host: localhost:4013
Connection: keep-alive
Content-Length: 0
Pragma: no-cache
Cache-Control: no-cache
Origin: http://localhost:4001
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36
DNT: 1
Accept: */*
Referer: http://localhost:4001/admin/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-CA,en;q=0.9,fr;q=0.8
HTTP/1.1 405 Method Not Allowed
Cache-Control: private
Allow: GET, HEAD, OPTIONS, TRACE
Content-Type: text/html; charset=utf-8
Server: Monsters/4.0
Date: Wed, 24 Jul 2019 15:47:58 GMT
Content-Length: 5298
... standard iis 500 page content...
The OPTIONS request and response from both is practially identical; the only change is the host (port) and timestamps. However, after the preflight, when hosted in IIS it responds with 405 Method Not Allowed and a different header Allow: GET, HEAD, OPTIONS, TRACE.
Is there something I need to add to the web.config for IIS specifically?
I'm just using the Chrome devtools to create an XMLHttpRequest for testing.
I have already removed WebDav from IIS.
The web.config is setup exactly as it would be from the linked tutorial.
I am running Windows 10 and IIS 10.
The only module I have installed is URL Rewrite, but no rules are enabled (and it is not configured in the web.config).
Thanks in advance for any hints as to what is going wrong.
I uninstalled WebDav then rebooted.
It's working.
...
Kill me.
Actually we send a cache control and expire header (normally cache control override the expire header) but we got a 304 response. Why does the navigator make this validation? Normally the navigator should not create a 304 because there is a cache control and it should use the cache. (browser is firefox)
GET page
Response is:
304 Not Modified
Accept-Ranges: bytes
Age: 16059
Cache-Control: public, max-age=21600
Connection: keep-alive
Content-Encoding: gzip
Content-Language: fr
Content-Type: text/html; charset=utf-8
Date: Fri, 22 Apr 2016 08:30:37 GMT
Etag: "1461297779-11"
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Fri, 22 Apr 2016 04:02:59 GMT
Server: Apache
Vary: Cookie,Accept-Encoding
Via: 1.1 varnish
X-BeResp-ttl: 21600.000
X-Country-Code: YT
X-Drupal-Cache: MISS
X-Forwarded-Region: 0
X-Varnish: 386264387 386223490
X-Varnish-Cache: HIT
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Connection: keep-alive
Host: www.domain.com
If-None-Match: "1461297779-11"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
I am using nginx and Adaptive Images to deliver dynamically sized images based on device resolution. The response headers being set by the adaptive-images.php file are shown below but every time I refresh the page the browser requests the images again. Why is the browser not caching these images? The browser is Google Chrome and it seems to be setting max-age=0 in the request headers no matter how I refresh. I've tried F5, Ctrl+F5 and entering the URL in the address bar and hitting Enter.
Request Headers:
GET /img/photos/p8.jpg HTTP/1.1
Host: example.com
Connection: keep-alive
Cache-Control: max-age=0
Accept: image/webp,*/*;q=0.8
Pragma: no-cache
If-Modified-Since: Wed, 16 Jul 2014 12:01:31 GMT
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.154 Safari/537.36
Referer: http://example.com/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,en-GB;q=0.6
Response Headers:
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 16 Jul 2014 12:08:55 GMT
Content-Type: image/jpeg
Content-Length: 391104
X-Powered-By: PHP/5.4.30
Cache-Control: private, max-age=604800
Expires: Wed, 23 Jul 2014 12:08:55 GMT
Last-Modified: Wed, 16 Jul 2014 12:08:55 GMT
Connection: Keep-Alive
It turns out that this seems to be a Chrome feature
See this other SO answer for why: Chrome doesn't cache images/js/css
Don't use control shift r when testing this (reload)
I have 2 domains mydomain.com and mydomain.org. The site lives at mydomain.org so I want any attempt to mydomain.com to resolve to mydomain.org.
The following mod_rewrite rule that works to a degree.
RewriteEngine on
RewriteCond %{HTTP_HOST} ^mydomain\.com$
RewriteRule ^ http://mydomain.org%{REQUEST_URI} [L,R=301]
After I implemented it and tested it I felt it was doing everything I needed until I submitted a form with method="post".
For some reason, this mod_rewrite trashes my _POST vars
I am working solely from mydomain.org (which is the TLD I want the site to resolve from and where I submitted the form from).
Does anyone know of an adjustment to my condition and rule to not lose the _POST vars?
I identified something interesting. I plugged-in the HTTP Live Headers add-on in Firefox. When I use the mod_rewrite I get an "HTTP/1.1 404 Not Found" and when I turn off mod_rewrite I get a "HTTP/1.1 200 OK". The same page and PHP code behind is used. Again, when I have the mod_rewrite directives turned off, the _POST data comes through. When I turn on the mod_rewrite directives, the _POST data does not come through.
MOD_REWRITE Turned Off:
http://dashausmuseum.org/subscribe.html
POST /subscribe.html HTTP/1.1
Host: dashausmuseum.org
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://dashausmuseum.org/subscribe.html
Cookie: __utma=74430599.461726749.1312575846.1312897084.1312899646.5; __utmz=74430599.1312575846.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=1.480711209.1312899756.1312979975.1312981669.5; __utmz=1.1312981669.5.5.utmcsr=dashausmuseum.com|utmccn=(referral)|utmcmd=referral|utmcct=/directions.html; __utmb=1.9.10.1312981669; PHPSESSID=7f4a74d7fde56cf901aa85511410b7f6; __utmc=1
Content-Type: application/x-www-form-urlencoded
Content-Length: 60
email=abc&firstName=&lastName=&address=&phone=&submit=Submit
HTTP/1.1 200 OK
Date: Wed, 10 Aug 2011 13:18:31 GMT
Server: Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.3.4
X-Powered-By: PHP/5.3.4
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 5420
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
MOD_REWRITE Turned On:
http://dashausmuseum.org/subscribe.html
POST /subscribe.html HTTP/1.1
Host: dashausmuseum.org
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://dashausmuseum.org/subscribe.html
Cookie: __utma=74430599.461726749.1312575846.1312897084.1312899646.5; __utmz=74430599.1312575846.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=1.480711209.1312899756.1312979975.1312981669.5; __utmz=1.1312981669.5.5.utmcsr=dashausmuseum.com|utmccn=(referral)|utmcmd=referral|utmcct=/directions.html; __utmb=1.10.10.1312981669; PHPSESSID=7f4a74d7fde56cf901aa85511410b7f6; __utmc=1
Content-Type: application/x-www-form-urlencoded
Content-Length: 60
email=xyz&firstName=&lastName=&address=&phone=&submit=Submit
HTTP/1.1 404 Not Found
Date: Wed, 10 Aug 2011 13:20:32 GMT
Server: Apache/2.2.17 (Unix) mod_ssl/2.2.17 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.3.4
X-Powered-By: PHP/5.3.4
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 5329
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
Does anyone see anything in the HTTP Headers that gives a clue as to what is going on?
Something else should be wrong, rewrite rules can't destroy _POST vars.
How are you setting/calling them in your code?
There is some discussion about what should happen to a POST transaction in response to a 301 (or other) redirect. Here is one example where the author suggests it is "messy".
Is it possible your browser is converting the POST to a GET request? Is it also possible the behavior is different in different browsers?
Clicking a link results in two calls for the page to the server. I install livehttp and inspected the header but can't figure out why it's sending the second request.
http://example.com/schedule?delete=290376
GET /schedule?delete=290376 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20110207 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://example.com/schedule
Cookie: Code=XXX; CodeHash=XXXXX
HTTP/1.1 200 OK
Date: Tue, 01 Mar 2011 22:09:51 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Set-Cookie: Code=XXXX; expires=Wed, 02-Mar-2011 00:09:52 GMT; path=/
Set-Cookie: CodeHash=XXXX; expires=Wed, 02-Mar-2011 00:09:52 GMT; path=/
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
----------------------------------------------------------
http://example.com/schedule?delete=290376
GET /schedule?delete=290376 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20110207 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://example.com/schedule
Cookie: Code=XXXX; CodeHash=XXXXX
HTTP/1.1 302 Moved Temporarily
Date: Tue, 01 Mar 2011 22:09:55 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Set-Cookie: Code=XXX; expires=Wed, 02-Mar-2011 00:09:55 GMT; path=/
Set-Cookie: CodeHash=XXX; expires=Wed, 02-Mar-2011 00:09:55 GMT; path=/
Location: http://example.org/schedule?errors=5
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
----------------------------------------------------------
In case you didn't find your solution:
I have stumbled on that same issue, and it seems to be related to the page encoding. If FireFox downloads a page containing invalid characters (for example, utf-8 chars inside a page for which the Content-type header is something else), then it will download the page a second time and parse it in the encoding it has tried to guess from the invalid chars it detected in the first page.
So make sure your page either returns the correct Content-type header, or contains a meta http-equiv header with the correct encoding.
You don't happen to be using firefox, have the web developer toolbar and also have the display page validation on do you?
I am guessing in the dark here as to your enviro but my team and I have been able to demonstrate that having that tool bar installed in firefox and having page validation set to display actually duplicates the POSTs and GETs as it sends that same page data to the validation service.