HTTP Caching problem. Request works on and off - apache

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

Related

Apache - Serving png as text / html

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.

How to Preventing Host Header Attack in Ubuntu Server 14.04

If we send a request from any host like example.com our server gives back a HTTP 1.1 200 OK response status.
In correct condition it should show either 302, 400 or 404 error message (not found response) status. At current condition it is showing 200 OK response message, when its send through our host like xx.xxx.xx.xx.
For example, if we sent this request:
GET /web/ HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Windows
NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0 Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5 Connection: close
Upgrade-Insecure-Requests: 1
We get this response:
HTTP/1.1 200 OK Date: Thu, 02 Mar 2017 15:23:20 GMT Server:
figi_Server X-Frame-Options: deny Strict-Transport-Security: 1 Vary:
Accept-Encoding X-Content-Type-Options: nosniff X-Frame-Options:
sameorigin X-XSS-Protection: 1; mode=block
Using
OS: Ubuntu 14.04.
Web server: Apache 2.2.
Virtual machine running both.
Please go through Screen Shot Of Issue for better Understanding of Issue:

how to use httpwebrequest to login to site in vb.net

i want to login to site with my account but using vb.net "httpwebrequest"
this is the header :
http://www.alexasurfing.com/login?task=user.login
POST /login?task=user.login HTTP/1.1
Host: www.alexasurfing.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:47.0) Gecko/20100101 Firefox/47.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
Referer: http://www.alexasurfing.com/login
Cookie: __cfduid=d09a17b9b5acf54646546541471462027; refid=14786;
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 159
username=GMAL%40gmail.com&password=PASWW&remember=yes
HTTP/1.1 303 See other
Date: Wed, 17 Aug 2016 19:30:48 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.5.9-1ubuntu4.17
Location: /dashboard/profile
Server: cloudflare-nginx
i dont know how to use httpwebrequest to login to the site with my account ?
See the example here:
HTTP request with post
your post data is: username=GMAL%40gmail.com&password=PASWW&remember=yes
Note: You are sending plain text password over http. If there's an https option you should use that.

Chrome Developer Tools network request reports excessive response time

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.

User authentication with XMLHttpRequest works in IE, not in Chrome?

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');