Getting response code 412 from curl, 200 from browser

[kanaldro]

Hello, I'm trying to clear cache for an nginx running with this fastcgi module (Debian 11, NGINX 1.19.6):

curl -s --http2 -H "Host: www.example.ro" -H "Accept-Encoding: gzip, deflate" -k "https://www.example.ro/purge/public-url-of-article" --resolve www.example.ro:443:172.16.10.29 -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.3"

In browser, accessing the purge url works ok, returns 200.

I spent two days on this.. what could trigger the 412/Precondition failed?

I added the User Agent because this is how I managed to solve it in an older server, desn't help this time....

Thanks!

[kanaldro]

Kind'a made it work, I used the Debugger from Chrome to export the reuqest.
My guess is this plugin is getting pretty old, new headers became the norm in the last few years and the overall nginx mechanics reacts to them.

This is my curl request that works:

curl -k 'https://www.example.ro/purge/public-url-of-article' \
  -H 'authority: www.example.ro' \
  -H 'pragma: no-cache' \
  -H 'cache-control: no-cache' \
  -H 'sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="98", "Google Chrome";v="98"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Linux"' \
  -H 'dnt: 1' \
  -H 'upgrade-insecure-requests: 1' \
  -H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36' \
  -H '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' \
  -H 'sec-fetch-site: none' \
  -H 'sec-fetch-mode: navigate' \
  -H 'sec-fetch-user: ?1' \
  -H 'sec-fetch-dest: document' \
  --resolve www.example.ro:443:172.16.10.29 \
  --compressed

• I'm using --resolve because I'm connecting with the server via the local intranet, via private class IP
  also -k is to ignore ssl certificate errors, I am using Cloudflare Origin ceritficates, usable only behind CF proxy.

P.S. to the DEVS, good job, it still gets the job done properly after all these years with a little bit of elbow grease :)
Thank Big G. there's github to share knowledge!