Using -X POST is often wrong as it "changes the actual method string in the HTTP request [... and] does not change behavior accordingly" (Stenberg, 2015).
Although, it is correct for the article's mention of "Send POST requests"... just that typically people don't send POST requests out of the blue with no data.
Here's the article in question. [0] I think runxiyu is correct.
The author delves a bit more into the issue.
> One of most obvious problems is that if you also tell curl to follow HTTP redirects (using -L or --location), the -X option will also be used on the redirected-to requests which may not at all be what the server asks for and the user expected. Dropping the -X will make curl adhere to what the server asks for. And if you want to alter what method to use in a redirect, curl already have dedicated options for that named --post301, --post302 and --post303!
Per the man page (`man 1 curl`),
> The method string you set with -X, --request will be used for all requests, which if you for example use -L, --location may cause unintended side-effects when curl does not change request method according to the HTTP 30x response codes - and similar.
`-d` and `--data` will appropriately change the headers of their requests. Funnily, `--post301` and `--post302` which have a similar effect as `-X POST` are RFC 7231 compliant, browsers just don't do that. [2][3] This is so ubiquitous that the error codes 307 and 308 were added to support the original behavior of repeating the request verbatim at the target address. Compare the following:
1. In the 301 case with just `--data`, the request turns into a GET request when sent to the redirect.
2. In the 301 case with `-X POST`, the request stays a `POST` request, but doesn't send any data to the redirect.
3. Finally, in the case where the server returns a 308, we see the POST request is kept and the data is resent.
To further expand slightly on a different thing that might surprise some people, the data options will automatically set the content type by adding the header, `Content-Type: application/x-www-form-urlencoded`, as if sending form data from a browser. This behvaior can be overridden with a manual `-H`, `--header` argument (e.g., `-H 'Content-Type: application/json`).
Edit: cube00 pointed out that newer versions of curl than mine have `--json` which will do that automatically. [4]
I have a pretty similar one. (Works off of the same concept) https://github.com/JasonLovesDoggo/caddy-defender if you're curious. Keep in mind this will not protect you against residential IP scraping.
The main reason for the non-JS solution is because a lot of people in communities around me, me included, generally block JS in their browsers, and I thought it'd be cool to have a non-JS PoW solution.
To be honest I would prefer if this could be computed with a simple shell script, but calling sha256sum in a loop is ridiculously slow. I might consider other methods of doing proof of work in the future (IIRC it's possible with argon2).
I agree. I also usually disable JavaScripts in the browser, and I think it is a good idea what you did with this. (Some users also may be using a browser without JavaScripts, so it is helpful with that too.)
I also agree that a simple shell script would probably be better, although nevertheless it is explained and someone could implement their own if they want to do, so it is good enough for now.
Although, it is correct for the article's mention of "Send POST requests"... just that typically people don't send POST requests out of the blue with no data.
reply