admin-ajax.php returning 404 status code sporadically - ajax

I have a new Wordpress site on a shared hosting environment that is not allowing me to save changes that I'm making in the theme customization panel. When I try to save, it pops up a window saying, "Looks like something’s gone wrong. Wait a couple seconds, and then try again."
I've used this panel to build this site up to this point. At first I was having sporadic failures to save. Then I would just wait a bit and it would save my changes. Now it's not saving any changes.
Looking at my network traffic, I see an obvious problem; admin-ajax.php is not found when I'm trying to save. Watching the network activity on that page, I can see that as I'm working, it's requesting this file (admin-ajax.php) over and over again. Some of the requests go through fine and some of them don't (either code 200 or 404). Those repeated accesses are apparently due to either an autosaving feature, a check to see that the user is logged in, or both. It also attempts to access that file on saving my working in the customization panel.
I've tried to compare the request and response headers as well as the parameters that are sent along with these requests to see if there is any difference that stands out and could lead me to a solution. So far, I don't see anything but you might.
Unsuccessful request:
Request headers:
Host: redacted.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://redacted.com/wp-admin/customize.php?return=%2Fwp-admin%2F
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 981
DNT: 1
Connection: keep-alive
Cookie: wordpress_3ae72dd3e5fcadd24ee59ff6b2db800f=redacted%7C1556173739%7CqfdnSqJucEmaB10OiEp18ejd33JajsNNqcoKByCFudSTg%7Cbc8d5c3384113c40964d2de489696aadf6c98c0f612e15dd2b13df8c3579818f; wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_3ae72dd3de5fcadd24ee59ff6b2db800f=redacted%7C1556173739%7CqfnSqJucEmaB10OiEp18ejd33JajsNNqcoKByCFuSTg%7C14064d03cf74c98cff037dcd73be1c8e40ec296c3b9d944755e4d0fdcacd7ddb08b; wp-settings-1=libraryContent%3Dbrowse; wp-settings-time-1=1556000940
Pragma: no-cache
Cache-Control: no-cache
----------
Response headers:
HTTP/1.1 404 Not Found
Server: nginx/1.14.2
Date: Tue, 23 Apr 2019 16:51:31 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Link: <http://redacted.com/wp-json/>; rel="https://api.w.org/"
Content-Encoding: gzip
Parameters:
wp_customize on
customize_theme twentyseventeen
nonce [redacted]
customize_changeset_uuid [redacted]
customize_autosaved on
customize_changeset_data {"nav_menu_item[-3955120765714645000]":{"value":{"object_id":49,"object":"page","menu_item_parent":0,"position":1,"type":"post_type","title":"Welcome","url":"http://mastermobilerepair.com/","target":"","attr_title":"","description":"","classes":"","xfn":"","status":"publish","original_title":"Welcome","nav_menu_term_id":2,"_invalid":false,"type_label":"Page"}},"nav_menu_item[-4393172170029273000]":{"value":false},"nav_menu_item[-6184586432959251000]":{"value":false},"nav_menu_item[-112932972895796220]":{"value":false}}
customize_changeset_autosave true
action customize_save
customize_preview_nonce [redacted]
And here's a successful request:
Request headers:
Host: redacted.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://redacted.com/wp-admin/customize.php?return=%2Fwp-admin%2F
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 230
DNT: 1
Connection: keep-alive
Cookie: wordpress_3ae72dd3e5fcadd24ede59ff6b2db800f=redacted%7C1d556173739%7CqfnSqJucEmaB10OiEp18ejd33JajsNNqcoKByCFuSTg%7Cbc8d5c3384113c40964dd2de489696aadf6c98c0f612e15dd2b13df8c3579818f; wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_3ae72dd3e5fcadd24ee59ff6b2db800f=redacted%7Cd1556173739%7CqfnSqJucEmaB10OiEp18ejd33JajsNNqcoKByCFuSTg%7C1406403cf74c98cff0d37dcd73be1c8e40ec296c3b9d944755e4d0fddcacd7b08b; wp-settings-1=libraryContent%3Dbrowse; wp-settings-time-1=1556000940
Pragma: no-cache
Cache-Control: no-cache
------------
Response headers:
HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Tue, 23 Apr 2019 16:52:24 GMT
Content-Type: application/json; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Robots-Tag: noindex
X-Content-Type-Options: nosniff
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Parameters:
data[check_changeset_lock] true
data[changeset_uuid] [redacted]
interval 60
_nonce [redacted]
action heartbeat
screen_id customize
has_focus true
wp_customize on
customize_preview_nonce [redacted]
I've also tried using other web browsers. I've tried Chrome (v. 73), Firefox (v. 66), and an older version of Safari. That didn't help.
I suspect that there's a Bayesian algorithm that's been triggered to recognize some of the parameters content and block it. I talked to my host and they said that mod_security was the problem and that they "whitelisted the rule ID manually from [their] end." I don't know what that means but I thought they would have made a change to my .htaccess file. I didn't see any changes when I looked today, so they may have been overwritten or otherwise I'm not looking in the right place.
My .htaccess contents are:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
I've tried adding
<IfModule mod_security.c>
SecFilterEngine Off
</IfModule>
to the top of the file (after # BEGIN WordPress), which also didn't help. So I'm lost. Any help is much appreciated.

This was resolved by my host. They whitelisted it for mod_security and that solved it.

Related

Why Firefox auto gzip download file?

I am working on a web file share service, the service can decompress the .gz file content before transferring to client if user asks for it: Windows has not gzip build-in.
Following is an example: un-gzip and download long.txt.gz.
Capture from Fiddler
Request
GET https://szdc-data-explorer-test.spiral.exchange/v1/fs/file/tmp/long.txt.gz?pipelines=ungzip&file_name=long.txt&otk=da39a3ee5e6b4b0d3255bfef95601890afd80709 HTTP/1.1
Host: szdc-data-explorer-test.spiral.exchange
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
DNT: 1
Connection: keep-alive
Referer: https://next-test.spiral.exchange/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Response
HTTP/1.1 200 OK
Cache-Control: no-store
Content-Disposition: attachment; filename="long.txt"
Content-Type: text/plain; charset=UTF-8
Date: Thu, 13 Jan 2022 00:44:14 GMT
Vary: Accept-Encoding
Vary: Origin
Content-Length: 293216
Firefox save the file with name long.txt as specified in Content-Disposition header, but the content is gzip-ed. It sounds like Firefox auto gzip due to request path ends with .gz: /v1/fs/file/tmp/long.txt.gz
Well, it is a known behavior of firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=610679

CORS header ‘Access-Control-Allow-Origin’ does not match in firefox, works in chrome

I'm making a simple cross-origin request request, which is blocked by firefox with reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘http://localhost:4200, *’).
The request headers are:
Host: localhost:8090
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0
Accept: application/json, text/plain, */*
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost:4200/schedule
Origin: http://localhost:4200
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Response Headers:
HTTP/1.1 200 OK
Server: nginx/1.10.3
Date: Wed, 11 Jul 2018 07:15:32 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 41359
Connection: keep-alive
Vary: Origin
Access-Control-Allow-Origin: http://localhost:4200
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Headers: *
Access-Control-Expose-Headers: *
As far as i can see, the origin and Access-Control-Allow-Origin match, but firefox seems to have a different opinion. The same setup works correctly with Chrome.
What am I missing here ?
Thanks,
Steven
The comment by #sideshowbaker put me on the right track: an add-on that i was using earlier for local testing seemed to intervene in the CORS exchange, even when it wasn't supposed to.
Removing it corrected the issue.

Https doesn't load some resources

I have problem using https for the website I'm working on. I'm using spring Security.
Everything work fine in http but when I use https one of my css file is not loaded, and some js file too.
My css file a liked like this
<link type="text/css" rel="stylesheet" href="common/css/gestion_donnees_ref.css>
so this is my request
GET /triWebapp/common/css/donnees_ref.css HTTP/1.1
Host: 10.24.192.169:444
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Accept: text/css,*/*;q=0.1
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: https://10.24.192.169:444/triWebapp/gestionDonneesReference
Cookie: JSESSIONID=eYvbCpcb2NNY4zvWtah3Rfhp
Connection: keep-alive
and the response
HTTP/1.1 302 Found
Date: Mon, 24 Nov 2014 15:43:08 GMT
Server: Apache
Location: http://tipi.hd.prod.me.edf.fr/triWebapp/common/css/donnees_ref.css
Content-Length: 250
Connection: close
Content-Type: text/html; charset=iso-8859-1
it seems that the conent type is wrong here but I don't know why.

Firefox/Mozilla personas errors -- URL change?

Has the location for Firefox/Mozilla personas changed? Looking at the error console I see:
GET https://addons.cdn.mozilla.net/en-US/firefox/_files/245568/firefoxtom.jpg [HTTP/1.1 404 Not Found 299ms]
Redownloading the persona gives:
GET https://addons.cdn.mozilla.net/user-media/addons/245568/firefoxtom.jpg [HTTP/1.1 200 OK 756ms]
For all my current personas, I only see the background color, not the image. Has something changed recently? Is there a workaround? FF 31. Thanks!
Hearing nothing, I'll assume it's a web server misconfiguration on Mozilla's part and that no one cares. Just for posterity, here is the request/response that I tried to post in comments above, but that didn't look very good.
https://addons.cdn.mozilla.net/_files/245568/firefoxtom.jpg?1288084876
Request Method: GET
Status Code: HTTP/1.1 301 Moved Permanently
Request Headers 09:25:39.000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0
Host: addons.cdn.mozilla.net
Connection: keep-alive
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Response Headers Δ305ms
X-Frame-Options: DENY
X-Backend-Server: web7
Vary: Accept-Language, User-Agent, X-Mobile
Strict-Transport-Security: max-age=31536000
Server: nginx
Location: https://addons.cdn.mozilla.net/en-US/firefox/_files/245568/firefoxtom.jpg?1288084876
Date: Sun, 07 Sep 2014 15:25:41 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Cache-Control: max-age=31536000

mod_rewrite condition and rule effects POST vars in a bad way

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?

Resources