[PATCH setup 11/11] Use wininet for fetching URLs in direct (non-proxy) case (DO NOT APPLY)

[Jon Turney]

On 02/05/2017 08:28, Ã
ke Rehnman wrote:
> Hello all,
>
> 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
> ftps yet.

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 
correctly, though.

> 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.

-- 
Jon Turney
Volunteer Cygwin/X X Server maintainer