This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH setup 11/11] Use wininet for fetching URLs in direct (non-proxy) case (DO NOT APPLY)
On 02/05/2017 08:28, Åke Rehnman wrote:
On 2017-05-01 22:45, Jon Turney wrote:
It seems this could be an existing bug which could have been triggered
the proxy case.
The attached incremental patch fixed this for me.
Seem to work fine for https and ftp now, I don't have the means to test
Thanks very much for testing.
One thought though, why not let wininet take care of file:// URL's as
well? Or actually don't try to parse the url string at all and just pass
it down to NETIO_IE5 unfiltered? The advantage is setup would be able to
I'd be happy to look at a separate patch to do this.
handle what ever protocols wininet has. Also letting wininet taking care
of file:// url's would let the user install from a local network
I'm pretty sure I've done that in the past, so I think it already works.
The form of file: URL required might not be strictly correct, though,
(I think file:////server/pathname/ ?)
I can't see how to get a file:// URL for a local directory to parse
resource (i.e file server). I'm been thinking of the case when someone
wants to use a local directory repo would be slightly more complicated
since relative paths does not work with file url's. One way to solve
this particular case would be to check the first character for '.' and
use that as an indicator to a local dir.
Looking at the code, it seems that anything that is not recognized as a
URL is just treated as a path, so this also may already be possible.
Volunteer Cygwin/X X Server maintainer