If you execute this and then SSH into the runner once the tmate session is setup and prints the connection details.
\nIf you now do
http -fp HBh POST https://store.rg-adguard.net/api/GetFiles type=ProductId url=9p804crf0395You get a \"403 Forbidden\" response.
\nIf you do the same just in the WSL distribution
wsl http -fp HBh POST https://store.rg-adguard.net/api/GetFiles type=ProductId url=9p804crf0395you get a \"200 OK\" response.
\nI cannot see why it is working from within the WSL distribution but not from the host system.
\nFrom 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
\nhttp https://api.ipify.org format==json | jq .ipand
\nwsl http https://api.ipify.org format==json | jq .ipI get the same IP
\nIf I do
\nhttp -fp b POST https://echo.free.beeceptor.com/api/GetFiles type=ProductId url=9p804crf0395and
\nwsl http -fp b POST https://echo.free.beeceptor.com/api/GetFiles type=ProductId url=9p804crf0395I get the exact same response.
\nIf 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=9p804crf0395and
\nwsl http -f POST http://my.serv.er:1234/api/GetFiles type=ProductId url=9p804crf0395I get the exact same bytes transferred.
\nI'm a bit lost why this behaves differently.
\nDoes anyone have any idea?
I finally got contact to the maintainer of that service and he luckily was very helping.
\nIt turns out, this is not caused by the GHA infrastructure.
\nThe service is protected by Cloudflare.
\nAnd 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.
\nNow that I added a User-Agent, the requests work again.
Thanks for everyone involved in trying to clear this up.
","upvoteCount":0,"url":"https://github.com/actions/runner-images/discussions/8791#discussioncomment-9569612"}}}Strange difference between host system and WSL system #8791
-
|
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. http -fp HBh POST https://store.rg-adguard.net/api/GetFiles type=ProductId url=9p804crf0395You get a "403 Forbidden" response. wsl http -fp HBh POST https://store.rg-adguard.net/api/GetFiles type=ProductId url=9p804crf0395you get a "200 OK" response. I cannot see why it is working from within the WSL distribution but not from the host system. If I do http https://api.ipify.org format==json | jq .ipand wsl http https://api.ipify.org format==json | jq .ipI get the same IP If I do http -fp b POST https://echo.free.beeceptor.com/api/GetFiles type=ProductId url=9p804crf0395and wsl http -fp b POST https://echo.free.beeceptor.com/api/GetFiles type=ProductId url=9p804crf0395I get the exact same response. If I listen to port 1234 on http -f POST http://my.serv.er:1234/api/GetFiles type=ProductId url=9p804crf0395and wsl http -f POST http://my.serv.er:1234/api/GetFiles type=ProductId url=9p804crf0395I get the exact same bytes transferred. I'm a bit lost why this behaves differently. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 27 replies
-
|
Hi @Vampire, we cannot answer right now, let us check this. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the update! Is there an internal ticket number or something, so i can try to get it escalated? |
Beta Was this translation helpful? Give feedback.
-
|
Any new information about this? |
Beta Was this translation helpful? Give feedback.
-
|
I finally got contact to the maintainer of that service and he luckily was very helping. Thanks for everyone involved in trying to clear this up. |
Beta Was this translation helpful? Give feedback.
-
|
@sergei-pyshnoi please take a look |
Beta Was this translation helpful? Give feedback.
-
|
We're locking this discussion because it has not had recent activity and/or other members have asked for more information to assist you but received no response. Thank you for helping us maintain a productive and tidy community for all our members. |
Beta Was this translation helpful? Give feedback.
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-Agentheader 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.