Windows: Detect scheme presence in proxy URLs more robustly#268
Windows: Detect scheme presence in proxy URLs more robustly#268janbrummer merged 1 commit intolibproxy:mainfrom
Conversation
Windows proxy servers can be set either with or without a scheme where without
implies http, and with or without a port where without implies the
default port for the scheme.
Unfortunately, g_uri_parse_scheme("proxy.example.com:3128") returns
"proxy.example.com" rather than NULL (while
g_uri_parse_scheme("1.2.3.4:3128") returns NULL), meaning that such
proxy configurations did not get http:// prepended to them, causing
e.g. GProxy to reject them.
With this change we simply search for the presence of :// in the URI
instead. While a URI technically doesn't have to contain // after
the scheme separator, such URIs should not occur in this context
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #268 +/- ##
=======================================
Coverage 73.19% 73.19%
=======================================
Files 16 16
Lines 843 843
Branches 238 238
=======================================
Hits 617 617
Misses 131 131
Partials 95 95 ☔ View full report in Codecov by Sentry. |
|
Sounds more like a bug which needs to be fixed in glib then. |
|
@mcatanzaro This looks really like a bug in glib as it assumes that the port is the real hostname and everything before is the scheme. I'm not sure whether it should return NULL in both cases or it should default to http? |
|
FTR: The error is in |
I'm not too familiar with the differences between URIs and URLs, but I suspect everything before the first : is the scheme. Certainly the scheme is not an optional URI component, and without it you don't have a URI that you can pass to GUri. I would prepend the http:// manually if desired. E.g. Epiphany does this in ephy_embed_utils_normalize_address(). |
|
I think you could argue that the behavior of glib here is technically correct according to RFC 3986. Key parts:
Thus I think a valid interpretation of As a comparison, here's what the urlparse function from Python's standard library does: As @mcatanzaro says, a string without a scheme is not a valid URI, thus using a URI parsing function to detect the presence/absence of a scheme was probably not the best choice (mea culpa). |
|
Good research! I'm merging this one. Thanks for your support. |
Windows proxy servers can be set either with or without a scheme where without implies http, and with or without a port where without implies the default port for the scheme.
Unfortunately, g_uri_parse_scheme("proxy.example.com:3128") returns "proxy.example.com" rather than NULL (while
g_uri_parse_scheme("1.2.3.4:3128") returns NULL), meaning that such proxy configurations did not get http:// prepended to them, causing e.g. GProxy to reject them.
With this change we simply search for the presence of :// in the URI instead. While a URI technically doesn't have to contain // after the scheme separator, such URIs should not occur in this context