We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Given the following upstream URL:
http://WINDOMAIN\MYUSER:[email protected]:8080
HoverFly fails with this response:
Could not parse upstream proxy: %!(EXTRA string=parse http://WINDOMAIN\MYUSER:[email protected]:8080: net/url: invalid userinfo)
Escaping the backslash has the same issue.
An alternative syntax using an @ symbol also fails, due to the first @ being interpreted as the prefix marker, not the last:
http://MYUSER@WINDOMAIN:[email protected]:8080
Curl accepts both URL forms.
The text was updated successfully, but these errors were encountered:
Just tried testing this for myself and got different but still unexpected results.
When testing it on Linux with
hoverctl start --upstream-proxy http://WINDOMAIN\MYUSER:[email protected]:8080
Hoverfly starts, but is configured with the incorrectly with the backslash ignored
"upstreamProxy":"http://WINDOMAINMYUSER:[email protected]:8080"
Also just tried
hoverctl start --upstream-proxy http://WINDOMAIN/\MYUSER:[email protected]:8080
Which I think worked? I'm unable to test the upstream working but Hoverfly does start with the upstreamProxy correctly configured.
"upstreamProxy":"http://WINDOMAIN/MYUSER:[email protected]:8080"
@AndyGee What OS are you using? Are you using hoverctl to start Hoverfly?
Sorry, something went wrong.
No branches or pull requests
Given the following upstream URL:
http://WINDOMAIN\MYUSER:[email protected]:8080
HoverFly fails with this response:
Could not parse upstream proxy: %!(EXTRA string=parse http://WINDOMAIN\MYUSER:[email protected]:8080: net/url: invalid userinfo)
Escaping the backslash has the same issue.
An alternative syntax using an @ symbol also fails, due to the first @ being interpreted as the prefix marker, not the last:
http://MYUSER@WINDOMAIN:[email protected]:8080
Curl accepts both URL forms.
The text was updated successfully, but these errors were encountered: