Skip to content

Conversation

@Poolitzer
Copy link
Member

@Poolitzer Poolitzer commented Mar 6, 2023

I decided to go for warning when a custom http://, not https:// URL is set. I also decided to call the next version 20.1.1, I think this issue warrants a release since users face errors because of us which are hard to spot/track down in production.

I also decided to change away the [http2] dependency, I hope this doesn't break anything.

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey! Looks like you edited README.rst or README_RAW.rst. I'm just a friendly reminder to apply relevant changes to both of those files :)

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey! Looks like you edited the (optional) requirements or the pre-commit hooks. I'm just a friendly reminder to keep the additional dependencies for the hooks in sync with the requirements :)

I don't think this is more readable but who am I to argue with deepsource.
@Poolitzer Poolitzer linked an issue Mar 6, 2023 that may be closed by this pull request
4 tasks
Copy link
Member

@Bibo-Joshi Bibo-Joshi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR!

I decided to go for warning when a custom http://, not https:// URL is set.

IISC the logic for the warnings-checking is not yet covering everything. After reviewing your changes, the different scenarios (all considering the user passed http_version="2") that I see are:

  • User is using cloud api -> base url starts with https://, local_mode is False, everything should work
  • User is using a self-hosted, non-local API server, with or without HTTP/1.1 proxy -> base_url can be either http://… or https://…, local_mode is False, will not work due to HTTP/2
  • User is using a self-hosted, non-local API server with a HTTP/2 proxy -> base_url can be either http://… or https://…, local_mode is False, will work due to proxy
  • User is using a self-hosted local API server with or without a HTTP/1.1 proxy -> base_url is http://…, local_mode is True, will not work due to HTTP/2
  • User is using a self-hosted local API server with a HTTP/2 proxy -> base_url can be http://… or https://…, local_mode is True, will not work due to proxy

In summary all combinations of http(s) & local_mode=True/False can either work or not work. IMO we should just issue a warning as soon as we know that the user is using a self hosted API server. This will give a few false positives, but it's only a warning after all …
I guess the only reliable way to check if the user is using a self-hosted API server is to check if "://api.telegram.org/" in base_(file_)url

I also decided to call the next version 20.1.1, I think this issue warrants a release since users face errors because of us which are hard to spot/track down in production.

Fine with me 👍

I also decided to change away the [http2] dependency, I hope this doesn't break anything.

Please make it a proper optional dependency via requirements-opts.txt and also add unit test for that :)

@Poolitzer
Copy link
Member Author

@Bibo-Joshi You mention base_file_url, I only check base_url. Do you really think it makes sense to (or) check base_file_url as well? You cant really use it without also changing base_url...

@Bibo-Joshi
Copy link
Member

@Poolitzer good point. base_url should be enough, then :)

Copy link
Member

@Bibo-Joshi Bibo-Joshi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the updates! The warning logic now LGTM :)

@Poolitzer Poolitzer marked this pull request as draft March 10, 2023 15:28
Poolitzer and others added 3 commits March 10, 2023 16:29
Co-authored-by: Bibo-Joshi <22366557+Bibo-Joshi@users.noreply.github.com>
Also broke the warning logic wuuups
Copy link
Member

@Bibo-Joshi Bibo-Joshi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! If there's nothing left from your side, we can merge IMO :)

@Poolitzer
Copy link
Member Author

@Bibo-Joshi Nothing from me

@Bibo-Joshi Bibo-Joshi marked this pull request as ready for review March 11, 2023 22:08
Copy link
Member

@harshil21 harshil21 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good, just 2 test class renaming suggestions..

Co-authored-by: Harshil <37377066+harshil21@users.noreply.github.com>
@Bibo-Joshi Bibo-Joshi merged commit 800598c into master Mar 12, 2023
@Bibo-Joshi Bibo-Joshi deleted the http2_downgrade branch March 12, 2023 15:30
@github-actions github-actions bot locked and limited conversation to collaborators Mar 20, 2023
@harshil21 harshil21 added this to the v20.2 milestone Mar 25, 2023
@harshil21 harshil21 added the 🛠 refactor change type: refactor label Mar 25, 2023
bigbabybubble referenced this pull request in father-bot/chatgpt_telegram_bot Jun 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

🛠 refactor change type: refactor

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] HTTP/2 yields errors

4 participants