Closed brlin-tw closed 1 month ago
I will look. TetherFi generally speaking does not change requests, but this may be sending extra data over as part of the HTTP connect step.
I will attempt to reproduce the issue on my end first.
Hi,
Testing against this URL: https://mirror01.idc.hinet.net/centos/7.9.2009/os/x86_64/repodata/repomd.xml using Firefox 123 on ArchLinux and MacOS, I was not able to recreate the 404.
While the page certainly loads slightly slower because of the proxy, I was able to get the XML file to load using both the latest main branch and the release build 40
Are you consistently able to reproduce the 404? Could there be something else at play like the server blocking an IP address, or some network configuration on your Android device preventing the connection?
@pyamsoft
First of all, apologies for the ignorance.
Are you consistently able to reproduce the 404?
Mostly yes, there is a minor case where the download will temporarily succeed after several refresh attempts on the web browser, however, most access does return 404.
Could there be something else at play like the server blocking an IP address
Nothing I would know of.
some network configuration on your Android device preventing the connection?
Not something I can think of.
Are you sure that yum
in the container is using the http_proxy variables, and that the proxy is set?
If you curl
the file outside of docker (with the proxy env set) does it work?
trying to isolate if this is a "docker network namespace" thing, or a "proxy http in the terminal" thing, thanks!
@pyamsoft
Are you sure that
yum
in the container is using the http_proxy variables, and that the proxy is set?
Absolutely:
If you
curl
the file outside of docker (with the proxy env set) does it work?
Nope:
I have manually built and installed version 41 from the source, and the problem is no longer reproduced.
Not sure what exactly fixes the issue, though, will it be helpful if I do a git bisect to locate the revision that changes the result?
All the HTTP requests that can readily reproduce the problem using the old version:
Not that it is insightful or anything.
All the HTTP requests that can readily reproduce the problem using the old version
I can verify that all these URLs can be successfully downloaded using the 41 version.
A slight change was made to how TCP connections were exchanged in 41. Maybe this has also fixed your problem?
Either way, its good to hear that 41 seems to have resolved the issue. I hope in the next few days Google will approve the build so it can release on the Play Store.
Can this be closed since the issue seems to be fixed in version 41?
Can this be closed since the issue seems to be fixed in version 41?
Yes, certainly.
I recently found that using TetherFi to fetch specific resources from some Linux distribution software archives (mirrors) will generate spurious HTTP 404 Not found errors:
I originally thought that it was the ISP who implemented faulty transparent proxies in between the connection that caches the erratic response however the problem is no longer reproduced after I unset the proxy settings and use the native USB tethering network sharing:
The issue can also be reproduced when I use the web browser to access the same URL(left: w/o TetherFi; right: w/ TetherFi):
I wonder whether there's any difference in the HTTP requests that are generated w/, w/o TetherFi that may trigger the different result?