-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify the use of http, but the client has been trying to connect using https #54
Comments
Try to fix this problem: |
Thanks for bringing this up, @badgv. I'd like to confirm we have identified the correct problem. I am concerned that qbittorrent/qBittorrent#5693 may be playing a role...but perhaps you've already mitigated that via some mechanism in At any rate, I believe To help me be sure I understand what is happening between First, can you please confirm exactly what curl -XHEAD -vvv --location http://127.0.0.1:6600/qb/api/v2/auth/login Additionally, can we take a look at the import logging
logging.basicConfig(level=logging.DEBUG, format='[%(asctime)s] {%(name)s:%(lineno)d} %(levelname)s - %(message)s')
import qbittorrentapi
qbt_client = qbittorrentapi.Client(host='http://127.0.0.1:6600/qb/', username='admin', password='adminadmin', VERBOSE_RESPONSE_LOGGING=True)
qbt_client.auth_log_in() Thanks again. |
My qb client uses nginx for reverse proxy and uses 192.168.168.3:8888/qb/ for access. curl test:
The API debug log is as follows:
It can be seen from the debug log above that after using http:// to access, the scheme was redefined as https due to an error in the requests.head test. [EDIT rmartin] formatting |
I used another proxy tool frp for testing, the api can work normally
curl test:
Use gost and frp proxy ports, both can be used normally in chrome browser, but gost proxy port api cannot work normally |
Interesting. Based on the API trace output, python cannot reach the qBittorrent endpoint with HTTP or HTTPS. When it tried the HTTP connection:
And then when it tried to connect via HTTPS:
Based on this, even if this client went ahead and used HTTP....I'm not sure the outcome would be any different. What does this output when you run it? import logging
logging.basicConfig(level=logging.DEBUG, format='[%(asctime)s] {%(name)s:%(lineno)d} %(levelname)s - %(message)s')
import requests
requests.post('http://127.0.0.1:6600/qb/api/v2/auth/login') |
6600 is frp port:
6677 is gost port:
Use gost and frp proxy ports, both can be used normally in chrome browser, but gost proxy port api cannot work normally [EDIT rmartin] formatting |
According to these tests, it seems that gost's port mapping implementation goes wrong? But the browser access is normal, which is very strange |
|
I don't think I had finished my coffee before reading the In the initial attempt to determine the URL, I didn't notice the
Then, the subsequent attempt to log in to qBittorrent hits a
When
Then, it re-tries to log in attempt...but this time using HTTPS...but this hits a
This whole process repeats one more time....and finally errors with
Sooo....sorry for perhaps going a bit in circles earlier.... That said, I am really not sure what's going on.....does your PR actually fix your problem in your environment? (in case it is useful, you can install a python package repo with I think we need to understand which intervening system (e.g. nginx, gost, frp, etc...or even qBittorrent i guess) is returning these [EDIT rmartin] as for the browser working with WebUI....that at least proves communication is possible and we can get this working....however, the browsers are a lot more robust at dealing with all these esoteric systems and surely have many more failsafes in place to fix problems on the fly...) |
Hello, I have modified the source code many times for testing,
Then I added the merge request code I submitted for testing:
I think we found the problem, and then I tried to modify the test:
This time the connection was made normally! |
Thank you for that investigation, @badgv. While bypassing the url scheme determination logic apparently avoids your problems, I am hesitant to make your requested changes without better understanding why Additionally, though, it would likely introduce problems for other users if I stopped doing the scheme determination altogether....since they may be depending on it without even knowing. All that said (and without knowing the true root cause of your problems), I am open to considering yet another flag to Something like qbt_client = qbittorrentapi.Client(host='http://127.0.0.1:6600/qb/', username='admin', password='adminadmin', FORCE_HOST_SCHEME=True) |
all right....if you'd like to give this update a go: python -m pip install git+https://github.com/rmartin16/qbittorrent-api.git@force-user-scheme#egg=qbittorrent-api Then, you can bypass scheme detection with qbt_client = qbittorrentapi.Client(host='http://127.0.0.1:6600/qb/', username='admin', password='adminadmin', FORCE_SCHEME_FROM_HOST=True) Thanks! |
qbt_client = qbittorrentapi.Client(host='http://127.0.0.1:6600/qb/', username='admin', password='adminadmin')
The error message is as follows:
Failed to connect to qBittorrent. Connection Error: ConnectionError(MaxRetryError("HTTPSConnectionPool(host='127.0.0.1', port=6600): Max retries exceeded with url: /qb/api/v2/auth/login (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f0a38170040>: Failed to establish a new connection: [Errno 111] Connection refused'))"))
I found that the error is caused by here:
qbittorrent-api/qbittorrentapi/request.py
369: r = requests_head(base_url.geturl(), allow_redirects=True, verify=False)
My listening address 127.0.0.1:6600 is transferred through a proxy called gost,
Proxy to my intranet address 192.168.1.100:8888.
When allow_redirects=True, it will cause the following error message:
HTTPConnectionPool(host='127.0.0.1', port=8888): Max retries exceeded with url: /qb/ (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f0ca86fa8b0>: Failed to establish a new connection: [Errno 111] Connection refused'))
Because the port is redirected from 6600 to 8888, and the host address remains at 127.0.0.1, the execution of requests.head fails
Then the scheme was redefined as alt_scheme='https'
The text was updated successfully, but these errors were encountered: