This repository has been archived by the owner on Apr 22, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 7.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
The change for #954 introduced a regression that would cause the url parser to fail on special chars found in the auth segment. Fix that, and also don't create invalid urls when format() is called on an object containing an auth member containing '@' characters or delimiters.
- Loading branch information
Showing
2 changed files
with
64 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I'm kind of lost in RFC land here. I suppose according to the RFC cited in this file (Reference: RFC 3986, RFC 1808, RFC 2396) this is the correct behavior for chars that need to be encoded?
Personally I was reading RFC1738 which has a different take on this:
Would like to clarify if I should / or shoudn't encode
?
in auth?