Allow for specifying schema in "proxy" - #1937
Conversation
whimboo
left a comment
whimboo
left a comment
There was a problem hiding this comment.
As it looks like this PR doesn't yet address the comment from #1920 (comment) for Safari.
While this looks way more flexible I'm not sure which of these provided alternatives are actually the best. It might be good to get at least consensus about that.
| <a><code>proxyType</code></a> is "<code>manual</code>". | ||
| <td>A <a>valid proxy per protocol specifiers</a> mutually exclusive with other | ||
| scheme-specific proxy configurations ("<code>httpProxy</code>", | ||
| "<code>sslProxy</code>", "<code>socksProxy</code>"). |
There was a problem hiding this comment.
We probably should have a processing algorithm as for other parts of the spec to actually enforce mutual exclusivity with httpProxy/sslProxy/socksProxy, validate incoming values, or handle unknown/unsupported schemes. Without this, implementations have no normative guidance on what to do.
| "default": { | ||
| "host": "proxy.example.com", | ||
| "port": 443, | ||
| "protocol": "socks5" |
There was a problem hiding this comment.
If an implementation (e.g. Safari) cannot route "https" traffic through a SOCKS5 proxy, there is no specified error code or behavior.
| </tr> | ||
|
|
||
| <tr> | ||
| <td><code>port</code> |
There was a problem hiding this comment.
Many proxy protocols have well-known default ports. Making port mandatory is stricter than any existing proxy field. Should we have it optional?
Co-authored-by: Henrik Skupin <mail@hskupin.info>
3 participants
Yet another approach for #1922 addressing #1920
Preview | Diff