-
Notifications
You must be signed in to change notification settings - Fork 973
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
Remove default_uri_parser
config
#1487
Comments
Just to add a case for "why we need it", I've run into a use case where The path thats getting passed in is
However, Addressable handles this just fine, correctly escaping the unicode
I came across this issue because I was trying to figure out why this exception was being raised at all, since I'm setting Addressable as our URI parser via an initializer. However, I discovered that the specific functionality needed was removed a few months back in #1484. I attempted to work around this by writing a custom middleware to handle the normalization, but it seems that that is further down the call-stack. For the time being, I've settled on pre-normalizing the path before passing it into Faraday. Regardless, thanks for your work on a great library :) |
Thank you for the great feedback @CKolkey, we'll definitely keep this scenario in mind when we get to work on this. |
This comment was marked as off-topic.
This comment was marked as off-topic.
hello there! I have a use-case that may not be shared by a majority of users and that is not exactly tied to this issue, but it's a neighbor topic I'd say. Basically, I wanted to implemented support for URI templates. The idea was being able to do I've since rolled out custom code that takes care of the template expansion ahead of calling It's possible overriding the default uri parser might have been a viable solution for rolling out my feature and it might have resulted in a better code design (or at least, something that could have been extracted into an open-source middleware) Also, I can understand that if it's not something that has been requested before, and if the use cases for overriding the URI parser is more a maintenance burden than anything else, dropping it makes sense. However, if it's not too much of a cost to keep it around, there's still use cases around for it. Happy to discuss this more if needed, and thanks for a solid library, well designed that is a pleasure to work with! |
This was introduced 9 years ago and it's unclear as to why we need it.
Most likely, back in the days the standard
Kernel#URI
was simply not powerful enough, which is arguably not true anymore.Moreover, by making this configurable without any rule, there's no way to tell what the return type of
Utils.URI
actually is, causing issues downstream and poor test coverage for edge cases that might result from the use of this configuration.Read more: #1484
The text was updated successfully, but these errors were encountered: