-
Notifications
You must be signed in to change notification settings - Fork 848
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
Don't overwrite CURLOPT_HTTP_VERSION option #586
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks good to me but I have some feels:
- we should update the readme
- we should likely add the version to the request headers (where we track curl and such) because we should be able to know
- not entirely sure I follow whether this could be a breaking change
- we likely need some kind of test? Not fully convinced
Can I ask that you re-assign to brandur or someone else than me? I'm always wary of approving core libs changes
I think this is already being covered by the "Custom cURL options" section and we don't need to cover every single option. Overriding the HTTP version should rarely be necessary.
I don't think this is necessary, we already know which HTTP version is being used. If we want to make it clearer in our own internal logs we can do that without relying on a custom header.
It's not. Even if someone is already passing a custom
I meant to write one, but it's actually difficult to test this without some refactoring. I'll give it another try though. |
Okay, so the only way we can test this right now is by switching the visibility of |
LGTM. |
Thank you both! |
Released as 6.29.1. |
r? @remi-stripe
cc @stripe/api-libraries
Don't force
CURLOPT_HTTP_VERSION
toCURL_HTTP_VERSION_2TLS
if a value is already set. This allows users to set their own value forCURLOPT_HTTP_VERSION
when using custom clients, e.g.: