Server response to ajax call with 200 but on browser I get error 400 on Safari - ajax

I have a strange behavior on a WordPress site. It is working just fine but several users (on safari) reported seeing error 400. While testing with safari I manage to reproduce the problem with changing the user-agent of the browser. Then I started getting error 400 on each ajax call. I've checked the access.log and all request to admin-ajax.php where served with status 200. But when I check the inspector in Safari, the same ajax request got status 400. And this is happening with each and every single ajax request on every page of the site. I've tried to log out/log in, cleared all cookies, cache and etc. but the error was still there.
The site uses ClouldFlare, so I went there and checked all the security and firewall rules, I didn't found my IP blocked anywhere.
So now the question is how a response with code 200 becomes 400?
Here is also the request and response of ajax call:
Summary
URL: https://www.example.com.com/wp-admin/admin-ajax.php
Status: 400
Source: Local Override
Address: yyy.yyy.yyy.yyy:zzz
Initiator: some-script.min.js:1:2080
Request
:method: POST
:scheme: https
:authority: www.example.com.com
:path: /wp-admin/admin-ajax.php
Accept: application/json, text/plain, */*
Content-Type: application/x-www-form-urlencoded
Origin: https://www.example.com.com
Cookie: some-cookies
Content-Length: 88
Accept-Language: en-us
Host: www.example.com.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15
Referer: https://www.example.com.com/units/main/
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Response
:status: 400
Date: Wed, 27 Jan 2021 12:27:47 GMT
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff
Cache-Control: no-cache, must-revalidate, max-age=0, no-store
X-Frame-Options: SAMEORIGIN
Content-Type: text/html
Access-Control-Allow-Credentials: true
Pragma: no-cache
Set-Cookie: some-cookies
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Access-Control-Allow-Origin: https://www.example.com.com
cf-edge-cache: cache,platform=wordpress
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
nel: {"max_age":604800,"report_to":"cf-nel"}
report-to: {"group":"cf-nel","endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report?s=some-token"}],"max_age":604800}
cf-cache-status: DYNAMIC
cf-request-id: 07e569767900001c377fb67000000001
cf-ray: 618278372fc81c37-SOF
x-robots-tag: noindex
Server: cloudflare
Request Data
MIME Type: application/x-www-form-urlencoded
action: my_ajax_callback
term_id: 1209
page_id
And this is the from the access.log:
xx.xxx.xx.xxx - - [24/Mar/2021:10:16:46 +0000] "POST /wp-admin/admin-ajax.php HTTP/1.0" 200 12203 "https://example.com/some-page/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15"
UPDATE
I have to say that this is happening only on Safari and no other browser. Also I'm running Safari in VM with Mojave, not sure if this is related, but I though it is worthy to mention this.
I have tried to pause the CF service, and this change was visible on all other browsers but Safari continued to server the site over CF (I can see in the response header server that its value was cloudflare while on the other browsers it was nginx). I've flushed the DNS in the terminal and restarted VM a few times but this didn't changed.
I have also disabled all the security and firewall features on CloudFlare after I enabled it again but this also didn't solve the problem. I'm starting to believe that the problem lies some where in Safari and not in CF.

Try turning Cloudflare off, the setting is called "Pause Cloudflare on Site" to isolate it and see if that makes a difference. Maybe you have some goofy modsec rules in place?

Related

Status 200 (from disk cache) and 304 Not Modified issue

I'm using Next.js custom server, which by default sends strong ETag header on each page GET request. For each request I also manually add Cache-Control header res.setHeader('Cache-Control', 'public, max-age=${60 * 60}, s-maxage=${60 * 60 * 24}, must-revalidate')
Also I'm using Cloudflare's loadbalancing and caching mechanism. According to this documentation https://support.cloudflare.com/hc/en-us/articles/218505467-Using-ETag-Headers-with-Cloudflare I sutisfied each requirement related to strong ETag. And the page rule was configured as following:
page rule configuration screenshot.
First strange behaviour is that on a client in headers I noticed for some reason weak ETag. Also the behaviour of caching is little strange. If I'll open a new site post, I'll be usually faced with cf-cache-status: HIT header, which means that Cloudflare already have prepared cache for this specific post. My expectation is that after page reloading in same tab, the page will be recreated form disk cache, but for some reason it makes a request, result of which is status 304 (Not Modified). BUT, if I'll copy the url and open the same post in new tab, it will be recreated from disk cache (as it should), and also after page reloading it makes request with response 304 (Not Modified).
Direct origin server request-response:
General:
Request URL: ...
Request Method: GET
Status Code: 200 OK
Remote Address: ...
Referrer Policy: strict-origin-when-cross-origin
Response headers:
cache-control: public, max-age=3600, s-maxage=86400, must-revalidate
connection: keep-alive
content-encoding: gzip
content-type: text/html; charset=utf-8
date: Thu, 28 Jan 2021 13:02:42 GMT
etag: "62e33-f1yLCVYVUzVH67UMp/2WOxQqfC8"
transfer-encoding: chunked
vary: Accept-Encoding
x-powered-by: Next.js
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, br
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7,uk;q=0.6
Cache-Control: no-cache
Connection: keep-alive
Cookie: _ga=GA1.1.1009400285.1608315387; _gid=GA1.1.1795438935.1611755271; _gat=1
Host: ip_here
Pragma: no-cache
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
Cloudflare proxy request-response:
General:
Request URL: ...
Request Method: GET
Status Code: 200
Remote Address: ...
Referrer Policy: strict-origin-when-cross-origin
Response headers:
age: 44448
cache-control: public, max-age=3600, s-maxage=86400, must-revalidate
cf-cache-status: HIT
cf-ray: 618ac665c984351f-KBP
cf-request-id: 07ea9a539d0000351f0faf7000000001
content-encoding: br
content-type: text/html; charset=utf-8
date: Thu, 28 Jan 2021 12:39:13 GMT
etag: W/"62e33-vLyavPBB7axQJnhj/OKdPyUNp+A"
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
nel: {"max_age":604800,"report_to":"cf-nel"}
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report?s=4ASHxxkyb8necnQhGaz8th4W%2FcFEwzrBwYiidFGsHK5ZZJ%2BGEYWbmOlDSC2Uep2TYw8vYUm0DL4WkrdC9xsIK%2F6j0G1QF%2BK5817fQQ%3D%3D"}],"max_age":604800,"group":"cf-nel"}
server: cloudflare
vary: Accept-Encoding
x-powered-by: Next.js
Request headers:
:authority: ...
:method: GET
:path: ...
:scheme: https
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, br
accept-language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7,uk;q=0.6
cache-control: max-age=0
cookie: _ga=GA1.2.33365049.1592837735; __cfduid=d58947d60ae6adfce59e944d190e702ae1610627770; _gid=GA1.2.788163791.1611406644; connect.sid=s%3AfLFtBQSejs6Jf0gkdqiRhyzAnu8ImE_J.KukkQj15FMXkfcW6alO6BPUYT8SgPWRqtu2xo2QRe8U; __cflb=0H28urhoa5eNWhDb7XVCL24Hq5fwW5bc37oc693mgWx; _gat=1
sec-fetch-dest: document
sec-fetch-mode: navigate
sec-fetch-site: same-origin
sec-fetch-user: ?1
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
Why is it happening? In ideal I want to recreate page from disk cache in nearest hour and after it make a revalidation request. And make Cloudflare's cache revalidation each day from origin server.
You can see in headers that ETag is different between origin server and cloudflare

Redirects stopped working in Firefox

I'm stumped, my website was working fine and now on Firefox suddenly the redirects stopped working.
I've tested IE and Chrome and going to /login redirects me to /dashboard however on Firefox the page is blank (no output sent) and no errors are logged. So this is why I'm assuming it to be a browser related issue. It might be due to a firefox update, but not sure how to confirm that.
Here are the headers:
Request Headers
GET /login HTTP/1.1
Host: local.example.com
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 FirePHP/0.7.4
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
DNT: 1
Cookie: __utma=34805930.947644602.1372214584.1380730296.1380733154.30; __utmz=34805930.1378700053.15.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); __utma=214248714.242656582.1377296111.1380047082.1380734348.30; __utmz=214248714.1377296111.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __qca=P0-705514134-1378344178153; __utmc=34805930; __utmb=34805930.15.10.1380733154; __utmb=214248714.5.10.1380734348; __utmc=214248714; PHPSESSID=lli8i30qkhvohfm9ufkbdvbki0
x-insight: activate
Connection: keep-alive
Response Headers
HTTP/1.1 302 Found
Date: Wed, 02 Oct 2013 17:30:58 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: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: /dashboard
Content-Length: 0
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
It all looks pretty standard to me, however FF stays stuck on /login Am I missing something?
This behaviour is both on my local windows host and my remote amazon Linux web-server. The body is empty...
How could I go about debugging this?
The Expires header field in the response is really off. Firefox probably does not bother to render stale responses.
Please check the system time in your server. It is possible it is an Amazon problem, but it is also possible that one of the server users set the system time.
You can look into setting up a Network Time Protocol (NTP) client to run regularly (with ntpd), if you don't have that yet.
I would fire up Fiddler to see what bits actually went over the wire. Among other information, Fiddler will show what content type is actually used during the HTTP request / response.
This could be related to the fact that there is no extension. Firefox could be having trouble determining if this is a document or folder. Try firebug and see what URL Firefox tries to request after the redirect.

Firefox CORS Cross Domain Resource Sharing Pre-Flight Debugging

I'm trying to get Firefox to allow me to make an XmlHttpRequest for data from an application port.
I can see that the initial send triggers an OPTIONS message, and I have trapped this using NetMon, and I can see the HTTP fields...
OPTIONS /any.htm HTTP/1.1
Host: www.mysite.co.uk:10090
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Origin: http://www.mysite.co.uk
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
I respond to this with an OK to tell FireFox to get a move on and send me the data in the XHR request...
HTTP/1.1 200 OK
Access-Control-Allow-Methods: POST,-GET,-OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 172800000
Server: Kawasu-OrderSub
Date: Wed, 23 Jan 2013 15:00:50 GMT
But the POST is never sent, which I assume means that FireFox is not happy with the 200 OK response. The POST sends data with a Content-Type of "application/json"
I've got FireBug and the Net tab has the XHR button, but this will only show the XHR after the pre-flight check has been passed.
Main Question: How can I see (and debug) what FireFox does not like about the server response?
Much obliged for any help in advance.
You need to include the Access-Control-Allow-Headers: content-type response header. This is because the request has the Access-Control-Request-Headers: content-type header, and this value needs to be included in the response.

Firefox leaking cookies across Websocket hostdomains

Within Firefox 9 & 10 using Firebug and Live Headers,
I am seeing the websocket request/response pairs being sent across domains but with the wrong Cookie: contents.
Give two urls -
Base web page - http://www.mysite.test/mywebapp
Websocket url - http://stompeserver.mysite.test/stomp
The browser seems to be sending the cookies for the base page hostname rather any cookies associated with the secondary hostname. i.e. the JSESSIONID cookie loaded with the base web page is being echoed to the external connection.
Is this a bug or expected behavior? Nowhere have I seen how to websockets are suppose react to cookies.
IMO, this can be a really serious security violation by exposing a site's cookies to an external websocket service.
Updated to firefox 10 and still see an issue.
Below is a slightly clarified Live Headers trace of two back to back connections
The JSESSIONID and CLIENT_LOCALE cookies are copied to from 9443 the app server to 61623 the mq server.
----------------------------------------------------------
https://myapp.com:9443/server/themes/standard/public/gwt/xxstandard/images/logout-icon.png
GET https://myapp.com:9443/server/themes/standard/public/gwt/xxstandard/images/logout-icon.png HTTP/1.1
Host: myapp.com:9443
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: https://myapp.com:9443/server/example.htm?gwt.codesvr=127.0.0.1:9997&log_level=INFO
Cookie: JSESSIONID=0000wCOpgfIsSNOz2lL22O5LOiI:-1; CLIENT_LOCALE=en_US;
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Date: Thu, 16 Feb 2012 19:02:55 GMT
Content-Type: text/plain
Last-Modified: Wed, 29 Jun 2011 20:44:11 GMT
Content-Length: 669
Content-Language: en-US
Server: WebSphere Application Server/7.0
----------------------------------------------------------
http://myapp.com:61623/stomp
GET http://myapp.com:61623/stomp HTTP/1.1
Host: myapp.com:61623
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
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
Proxy-Connection: keep-alive
Sec-WebSocket-Version: 8
Sec-WebSocket-Origin: https://myapp.com:9443
Sec-WebSocket-Key: FToA/HGiVQN3CbGOgNffMA==
Cookie: JSESSIONID=0000wCOpgfIsSNOz2lL22O5LOiI:-1; CLIENT_LOCALE=en_US;
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Connection: Upgrade
HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: 5lqrLU4mbPiEasSn4gqOlqWvGgw=
----------------------------------------------------------
Same-origin policy and CORS doesn't apply to WebSockets.
With WS, a "origin" HTTP header is sent in the initial WS opening handshake, and for browsers, this origin header MUST contain hostname of the server that originally served the HTML/JS that opens the WS.
The WS server is then free to accept/deny.
With non-browser WS clients, the origin header may or may not be present, and may contain anything.
Cookies: it's not specified by the WS spec. See Patrick's response (Firefox WS developer) here
http://www.ietf.org/mail-archive/web/hybi/current/msg08017.html

Can not log out from Tomcat using Firefox

I've encountered quite unexpected problem using Tomcat and CAS authorization. I just cannot logout in Firefox. I'm redirected to the logout page, but as soon as I reenter application url in the address bar, it is opened as if I'm logged (and I'm logged actually!).
First I've take a notable amount of attempts to fix something in tomcat config, then I've read logs, but nothing helped me actually before it comes up to my mind to check logout behavior in other browsers.
In other browsers everything work just as expected.
And I'm just stuck and would appreciate if one will give me a hint.
I guess [this question][1] is in some way relative with mine, but, helas, disabling caching on the page which should me logouted doesn't help either.
UPD: Some debug information. Firefox's version is 7.0.1, unfortunately, it is not a public application and I can not provide any url. It looks like response.sendRedirect output is something that Firefox is missing. Here is minimal code that works in any browser except Firefox.
session.invalidate();
response.sendRedirect("https://app:8552/cas/logout");
HEADERS
1st REQUEST - which invalidates session and redirect to CAS logout page
REQUEST HEADERS
Host: dev.service.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
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://dev.service.net/
Cookie: JSESSIONID=53B9469EFE9F130E9694F7406BFAB755
RESPONSE HEADERS
Server: nginx/1.0.4
Date: Thu, 20 Oct 2011 09:20:45 GMT
Content-Type: text/html
Content-Length: 184
Location: https://dev:8552/cas/logout
2nd REQUEST - cas logout page itself
REQUEST HEADERS
Host: dev:8552
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
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://dev.service.net/
Cookie: JSESSIONID=8A68F008825A0F0D14C6BF803E1332CF; GUEST_LANGUAGE_ID=en_US; COOKIE_SUPPORT=true
RESPONSE HEADERS
Server: Apache-Coyote/1.1
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache, no-store
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 1226
Date: Thu, 20 Oct 2011 15:53:57 GMT
3rd REQUEST - we are retuninig to the page which actually should
redirect us to login page, but it does not.
REQUEST HEADERS
Host: dev.service.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
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
Cookie: JSESSIONID=53B9469EFE9F130E9694F7406BFAB755
RESPONSE HEADERS
Server: Apache-Coyote/1.1
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache, no-store
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 1226
Date: Thu, 20 Oct 2011 13:30:51 GMT
According to the headers, you're maintaining two different sessions on two different hosts. When you request a logout on the first host, you're redirected to the second host (which uses a different session cookie). The session cookie of the second host is in turn indeed invalidated (according to the presence of the Set-Cookie header). But based on the last request, the session has not been recreated on the server side (there is no Set-Cookie header). This means that session.invalidate() before response.sendRedirect() has failed somehow, or that the page is actually requested from the browser cache.
In Firebug you should be able to see if the page is requested from the browser cache by checking the text color of the request in the Net tab. If it's grayed out, then it means that it's been served from the browser cache. For Firefox, the must-revalidate header is actually mandatory next to the no-cache, no-store headers. You need to configure your server to add that entry to the header, or to change/create a Filter for that.
See also:
How to control web page caching, across all browsers?

Resources