Strange difference between host system and WSL system

[Vampire]

Given the following workflow:

name: Debug
on:
  push: {}
jobs:
  test:
    name: Test
    runs-on: windows-latest
    steps:
    - name: Setup Debian
      uses: Vampire/setup-wsl@v2
      with:
        distribution: Debian
        additional-packages: python3-pip
    - name: Install HTTPie in Debian
      shell: wsl-bash {0}
      run: python3 -m pip install --upgrade pip wheel httpie
    - name: Install HTTPie in Windows
      run: python -m pip install --upgrade pip wheel httpie
    - name: Check Python version in Debian
      shell: wsl-bash {0}
      run: python3 --version
    - name: Check Python version in Windows
      run: python --version
    - name: Check HTTPie version in Debian
      shell: wsl-bash {0}
      run: http --version
    - name: Check HTTPie version in Windows
      run: http --version
    - name: Setup tmate session
      uses: mxschmitt/action-tmate@v3
      if: always()

If you execute this and then SSH into the runner once the tmate session is setup and prints the connection details.
If you now do

http -fp HBh POST https://store.rg-adguard.net/api/GetFiles type=ProductId url=9p804crf0395

You get a "403 Forbidden" response.
If you do the same just in the WSL distribution

wsl http -fp HBh POST https://store.rg-adguard.net/api/GetFiles type=ProductId url=9p804crf0395

you get a "200 OK" response.

I cannot see why it is working from within the WSL distribution but not from the host system.
From the host system it also worked fine until recently before the tests for my setup-wsl action went to red because of this.

If I do

http https://api.ipify.org format==json | jq .ip

and

wsl http https://api.ipify.org format==json | jq .ip

I get the same IP

If I do

http -fp b POST https://echo.free.beeceptor.com/api/GetFiles type=ProductId url=9p804crf0395

and

wsl http -fp b POST https://echo.free.beeceptor.com/api/GetFiles type=ProductId url=9p804crf0395

I get the exact same response.

If I listen to port 1234 on my.serv.er using nc -l -p 1234 | xxd and then do

http -f POST http://my.serv.er:1234/api/GetFiles type=ProductId url=9p804crf0395

and

wsl http -f POST http://my.serv.er:1234/api/GetFiles type=ProductId url=9p804crf0395

I get the exact same bytes transferred.

I'm a bit lost why this behaves differently.
Does anyone have any idea?

[Alexey-Ayupov]

Hi @Vampire, we cannot answer right now, let us check this.

[mikhailkoliada]

we have identified that the problem is not in the GitHub's runner image but in the windows azure sku, we'll hand over that to them but no eta

[ljharb]

Thanks for the update! Is there an internal ticket number or something, so i can try to get it escalated?

[Vampire]

Any new information about this?

[Vampire]

I finally got contact to the maintainer of that service and he luckily was very helping.
It turns out, this is not caused by the GHA infrastructure.
The service is protected by Cloudflare.
And the requests I made from the action had no User-Agent header set which Cloudflare seems to have stopped liking and thus sent the request to the anti-bot waiting room.
Now that I added a User-Agent, the requests work again.

Thanks for everyone involved in trying to clear this up.

[mikhailkoliada]

@sergei-pyshnoi please take a look