Using the Chrome network panel, I find that I have one request which keeps returning as 16027.6 days long. Considering how that's longer than my entire life so far, that seems excessive.
Request headers:
GET /performance/login/ HTTP/1.1
Host: 192.168.2.92
Connection: keep-alive
Cache-Control: max-age=0
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36
X-Requested-With: XMLHttpRequest
Referer: https://192.168.2.92/performance/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: PHPSESSID=qu9e2tbjn98mge14ifpkqf7go4; cw=ee2da41084f3ebaa9012f1120558e4faee99d0e8; session=a%3A8%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2270de4726ca6e81e779947f11327c492a%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A12%3A%22192.168.2.92%22%3Bs%3A10%3A%22user_agent%22%3 Bs%3A108%3A%22Mozilla%2F5.0+%28Windows+NT+6.1%3B+WOW64%29+AppleWebKit%2F537.36+%28KHTML%2C+like+Gecko%29+Chrome%2F31.0.1650.57+Safari%2F537.36%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1384802015%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3Bs%3A4%3A%22user%22%3Ba%3A8%3A%7Bs%3A2%3A%22id%22%3Bs%3A3%3A%22731%22%3Bs%3A8%3A%22username%22%3Bs%3A9%3A%22support_m%22%3Bs%3A4%3A%22name%22%3Bs%3A4%3A%22Mark%22%3Bs%3A5%3A%22email%22%3Bs%3A31%3A%22moberemk%40publicsectordigest.com%22%3Bs%3A5%3A%22admin%22%3Bs%3A1%3A%221%22%3Bs%3A7%3A%22perf_db%22%3Bs%3A9%3A%22perf_kenn%22%3Bs%3A6%3A%22client%22%3Bs%3A9%3A%22Kennedale%22%3Bs%3A9%3A%22client_id%22%3Bs%3A3%3A%22731%22%3B%7Ds%3A9%3A%22logged_in%22%3Bb%3A1%3Bs%3A15%3A%22app_preferences%22%3Ba%3A2%3A%7Bs%3A12%3A%22trend_period%22%3Bs%3A1%3A%226%22%3Bs%3A10%3A%22trend_unit%22%3Bs%3A6%3A%22months%22%3B%7D%7D65fd2545afa3a2c283d575b9278fbb1c
Response Headers:
HTTP/1.1 200 OK
Date: Mon, 18 Nov 2013 19:17:41 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
X-Powered-By: PHP/5.4.7
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: max-age=172800, public, must-revalidate
Pragma: no-cache
Set-Cookie: session=a%3A8%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2270de4726ca6e81e779947f11327c492a%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A12%3A%22192.168.2.92%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A108%3A%22Mozilla%2F5.0+%28Windows+NT+6.1%3B+WOW64%29+AppleWebKit%2F537.36+%28KHTML%2C+like+Gecko%29+Chrome%2F31.0.1650.57+Safari%2F537.36%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1384802015%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3Bs%3A4%3A%22user%22%3Ba%3A8%3A%7Bs%3A2%3A%22id%22%3Bs%3A3%3A%22731%22%3Bs%3A8%3A%22username%22%3Bs%3A9%3A%22support_m%22%3Bs%3A4%3A%22name%22%3Bs%3A4%3A%22Mark%22%3Bs%3A5%3A%22email%22%3Bs%3A31%3A%22moberemk%40publicsectordigest.com%22%3Bs%3A5%3A%22admin%22%3Bs%3A1%3A%221%22%3Bs%3A7%3A%22perf_db%22%3Bs%3A9%3A%22perf_kenn%22%3Bs%3A6%3A%22client%22%3Bs%3A9%3A%22Kennedale%22%3Bs%3A9%3A%22client_id%22%3Bs%3A3%3A%22731%22%3B%7Ds%3A9%3A%22logged_in%22%3Bb%3A1%3Bs%3A15%3A%22app_preferences%22%3Ba%3A2%3A%7Bs%3A12%3A%22trend_period%22%3Bs%3A1%3A%226%22%3Bs%3A10%3A%22trend_unit%22%3Bs%3A6%3A%22months%22%3B%7D%7D65fd2545afa3a2c283d575b9278fbb1c; expires=Mon, 18-Nov-2013 21:17:42 GMT; path=/
Status: 200
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 153
Keep-Alive: timeout=5, max=90
Connection: Keep-Alive
Content-Type: application/json
I'm not sure exactly what my web server is doing to trigger this, so I'm thinking this might be a Chrome-specific bug. Thoughts?
Looks like a time issue. Check the date on both local and remote machines. That response time is pretty close to the days since epoch which would indicate for some reason the server thinks it's 1970.
If you go to http://www.epochconverter.com/ copy the epoch time at the top (something like 1384805814), enter it in "Convert seconds to days, hours and minutes", you will get something like "16027 days, 20 hours, 16 minutes and 17 second" which is pretty close to what you're seeing in the console.
It's strange, though, to see Date in the response headers as correct and at the same time an expire for sometime in 1981...almost as if webserver is using one date and php is using another.
The solution will depend on what the stack you are using is. https://serverfault.com/ would be a better place to ask for help with the issue.
Related
I'm facing a weird behaviour on chrome with http get requests that most likely has something to do with cache.
Basically, the same request returns 200 the first time, then if I send the same request again by entering again the URL bar it returns 404. THen again 200. Then 404.
The request looks something like this (by using the dev tools on chrome) I use ## to hide sensitive info
General:
Request URL: ###
Request Method: GET
Status Code: 200 OK
Remote Address: ##############
Referrer Policy: strict-origin-when-cross-origin
Response Headers:
Accept-Ranges: bytes
Cache-Control: max-age=0, no-cache
Content-Length: 75209
Content-Type: application/json
Date: Fri, 10 Sep 2021 10:29:22 GMT
ETag: W/"IDGfBPV6nmAIDGefDH3A0M"
Last-Modified: Wed, 08 Sep 2021 08:36:01 GMT
Server: Jetty(9.4.z-SNAPSHOT)
Request headers
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en,it-IT;q=0.9,it;q=0.8,en-US;q=0.7
Connection: keep-alive
Cookie: ##################
Host: #########
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36
If i now press enter in the URL bar issuing the request again i get the following response:
General
Request URL: ####
Request Method: GET
Status Code: 404 Not Found
Remote Address: ######
Referrer Policy: strict-origin-when-cross-origin
Response Headers
Cache-Control: must-revalidate,no-cache,no-store
Content-Length: 347
Content-Type: text/html;charset=iso-8859-1
Date: Fri, 10 Sep 2021 10:29:05 GMT
ETag: W/"IDGfBPV6nmAIDGefDH3A0M"
Server: Jetty(9.4.z-SNAPSHOT)
Request Headers
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en,it-IT;q=0.9,it;q=0.8,en-US;q=0.7
Cache-Control: max-age=0
Connection: keep-alive
Cookie: #################
Host: ####
If-Modified-Since: Wed, 08 Sep 2021 08:36:01 GMT
If-None-Match: W/"IDGfBPV6nmAIDGefDH3A0M"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36
And so on, 200, 404, 200, 404 ...
Differences I noticed are in the Cache-Control header of the response and the new If-Modified-Since and If-None-Match request headers.
The backend server is a proprietary server and between the client there is an Apache Proxy Server.
I know that to get the solution I should provide more data (maybe the httpd configuration) but I'm more like trying to understand what the issue is rather than asking for a magic solution.
I searched on google "Get request works on and off" and all sort of wording variations but had no luck.
If anyone could help me out at least understanding the problem
Thanks
Davide
UPDATE
As Kevin suggested in the comment, shutting down the apache proxy did not change this on/off behaviour. Has to be something within the origin server
The server log says:
[04/Nov/2019:23:11:23 +0100] "GET /imgs/flags/fr.png HTTP/1.1" 200 2173 "http://XXXXX.com/user/start" "Mozilla/5.0 (Linux; Android 5.0; SM-G900P Build/LRX21T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3959.0 Mobile Safari/537.36"
However, they are being served as text:
This is only happening in production though... in localhost it works fine.
This image loads ok: /imgs/logo_only_transparent.png
This image does not load: /imgs/flags/es.png
Using Ubuntu 18.04, php 7.2, Laravel 6, Vue 2.x
What am I missing?
From the network tab:
Request Method: GET
Status Code: 200 OK
Referrer Policy: no-referrer-when-downgrade
Cache-Control: no-cache, private
Connection: Keep-Alive
Content-Encoding: gzip
Content-Length: 1205
Content-Type: text/html; charset=UTF-8
Date: Mon, 04 Nov 2019 22:11:23 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.29 (Ubuntu)
Set-Cookie: XSRF-TOKEN=eyJpdiI6IkFcL3lRY2JcL0o1R0VyNmRzeXdHcytsQT09IiwidmFsdWUiOiJMNWoyeUUyeW1lMG4zOFNRWnVDWG5jRU1FOFU2bVRuTzl6WmZqQlwvVGFXdnhQWVBVM29vbW1JTEszMldlXC9ra1IiLCJtYWMiOiJjM2JmODA4M2RiODVjZjJjODM5NTliYTFiMzI3NzU2ZDk0YjQwNmY3YTU3YzE1NmE3NzI3ZDM2YTIxODQ2YTY3In0%3D; expires=Tue, 05-Nov-2019 00:11:23 GMT; Max-Age=7200; path=/
Vary: Accept-Encoding
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: es,en;q=0.9
Connection: keep-alive
EDIT (Solved): The reason was that the file is named ES.png no es.png. Apparently this is not an issue when running XAMPP in Windows but it when running it in Ubuntu.
My browser send to the server the following request:
Host: www.imprimante.be
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: */*
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
If-Modified-Since: Fri, 29 May 2015 14:22:44 GMT
If-None-Match: "90-5173935ad3a1a-gzip"
Referer: http://www.imprimante.be/premier-avis-gratuit/
Cookie: <hidden>
Connection: keep-alive
The url used is http://www.imprimante.be/wp-content/themes/mch_imprimante/js/theme.min.js? (note: www.imprimante.be is not accessible trough wlan yet)
And the server send me the file with this (status 200) http header:
Accept-Ranges: bytes
Connection: Keep-Alive
Content-Encoding: gzip
Content-Length: 137
Content-Type: application/javascript
Date: Wed, 03 Jun 2015 07:18:03 GMT
Etag: "90-5173935ad3a1a-gzip"
Keep-Alive: timeout=5, max=99
Last-Modified: Fri, 29 May 2015 14:22:44 GMT
Server: Apache/2.4.10 (Debian)
Vary: Accept-Encoding
As you might notice (Last-Modified: Fri, 29 May 2015 14:22:44 GMT) the file hasn't been modified since the last request.
So I don't get why the response isn't a 304 status: not modified.
I'd really like to know why the caching of this files (and some others) doesn't work as I expect it.
It is bug in Apache. Turn off mod_deflate.
Sometimes my IIS server starts responding with 304 HTTP status to non-conditional requests. I have yet to determine exactly when this happens, but when it starts all browsers keep getting 304.
This is the request (debugged using fiddler):
GET http://www.example.com/aaa/bbb/GetStaticResult HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
Accept: */*
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://localhost:12345/xxx
Origin: http://localhost:12345
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
And the response:
HTTP/1.1 304 Not Modified
Cache-Control: public
Expires: Thu, 30 Apr 2015 09:23:22 GMT
Last-Modified: Wed, 30 Apr 2014 09:23:22 GMT
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Wed, 30 Apr 2014 10:33:58 GMT
The ASP.NET MVC method is the following:
[HttpGet]
[OutputCache(Duration = int.MaxValue, VaryByParam = "")]
public string GetStaticResult()
{
return "static";
}
The request hasn't any If-Modified-Since (or similar) header. Shouldn't the server issue a 200 response?
May be related with Getting a 304 if there is no If-Modified-Since sent?
The following function works in IE but not in Chrome:
function doStuff() {
var request = new XMLHttpRequest();
request.open("POST", "http://twitter.com/statuses/update.json", true, "USERNAME-HERE", "PASSWORD-HERE");
request.send("status=STATUS UPDATE HERE");
}
Chrome generates the following request. Note the Authorization header is missing:
OPTIONS /statuses/update.json HTTP/1.1
Host: twitter.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.78 Safari/532.5
Access-Control-Request-Method: POST
Origin: file://
Access-Control-Request-Headers: Content-Type
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
I get the following response (http 401):
HTTP/1.1 401 Unauthorized
Date: Wed, 03 Feb 2010 00:39:33 GMT
Server: hi
Status: 401 Unauthorized
WWW-Authenticate: Basic realm="Twitter API"
X-Runtime: 0.00107
Content-Type: application/json; charset=utf-8
Cache-Control: no-cache, max-age=300
Set-Cookie: _twitter_sess=BAh7BzoHaWQiJTUxMTc2Nzk4N2U0YzMzZmU0ZTQyNzI4NjQyYjI3ODE2Igpm%250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG%250AOgpAdXNlZHsA--bb61324c3ba12c3cd1794b3895a906a69c154edd; domain=.twitter.com; path=/
Expires: Wed, 03 Feb 2010 00:44:33 GMT
Vary: Accept-Encoding
Content-Length: 73
Connection: close
{"request":"/statuses/update.json","error":"Could not authenticate you."}
So, how am I supposed to pass a username and password to XHR? Webkit/Safari documentation says the open method should take these parameters, so I'm not sure why it is failing.
The solution was that I needed to add
request.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
The way I'm doing this is... special... so this may not be of much use to others going forward. But once I added this webkit started adding Authorization.
From the look of it, you're trying to do an X-Domain XMLHTTPRequest, which is why Chrome sends the OPTIONS pre-flight request. Because the Twitter server doesn't respond to the OPTIONS request indicating that X-Domain access is okay, you get a failure here.
Your code would only work in IE in the Local Computer zone, or if you turn off x-domain-checking (very dangerous)
Have you tried:
request.setRequestHeader('Authorization', 'yourvalue');