Exact same request gives different response on Linux compared to Windows

57 Views Asked by At

I am trying to execute the following the request (which returns a 200 OK response on Windows) under WSL (and also on a seperate remote Linux server where the same thing happens):

curl https://www.ah.nl/ -H "User-Agent:"

Instead of the desired 200 response, when executing the same request under WSL, I get a 403 Forbidden response with an access denied page. The server I'm trying to contact seems to hate Linux for some reason, but that doesn't make any sense because it originates from the same computer connected to the same WiFi-network with the same IP-address (this is of course not true in the case of the remote Linux server).

Note that this question is not about curl, and doesn't have anything to do with curl. I've tried the request with Node.js fetch, Python3 requests as well as Rust reqwest on both WSL and the Windows host and the exact same thing happens. Idem when running from my external Linux server.
+I even tried curl in Termux on my phone on a mobile network. I know for a fact I can't be IP-blocked or anything like that because I can access the website through my browser.

UPDATE: It gets worse. Running Firefox through WSL does allow me to access the website like normal, and copying the request from within Firefox in WSL as cURL (from the Network tab in DevTools) and executing the command that gives me does again not work. I swear to god computers are evil. This goes against everything I know about HTTP, network communication and basic logic in general.

UPDATE 2: This is important. I tried executing the request from WSL through a debugging proxy (Fiddler), which makes it succeed (which also means I have no lost the very last thing in my power to try to analyse what's happening as far as I know...). This should (I really want to not say 'should' but at this point I don't trust anything) rule out the request itself being at fault, meaning it has to do with how it is transmitted to the server (does that even make sense??) however that doesn't explain why Firefox in WSL was able to obtain the desired response.

UPDATE 3: Ran the request through mitmproxy on WSL, which also makes it succeed somehow. Does this mean the issue is caused by the HTTP client libraries on Linux? At least I know it means I'm unable to analyse the request which receives the 403 Forbidden response (although I guess I could different proxies still).

What's going on? How is the server able to figure out at least something is different? What about both requests is not exactly the same?

0

There are 0 best solutions below