[PATCH setup 11/11] Use wininet for fetching URLs in direct (non-proxy) case (DO NOT APPLY)
Jon Turney
jon.turney@dronecode.org.uk
Wed May 3 16:37:00 GMT 2017
On 02/05/2017 20:29, Ã
ke Rehnman wrote:
>>> 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.
> See proposed incremental patch. Have a look, give me your thoughts.
>>
>>> 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/ ?)
> Seem to work with \\server\share_name\path or //server/share_name/path
> now anyway
Thanks for the patch. So there are a few separate things here:
* Pass unknown protocols to wininet
This seems a fine idea, but isn't what this patch does.
* Allow wininet to handle file:// URLs
I'm a little bit concerned that there may be current uses which rely on
the incorrect parsing we do of file:// URLs to work.
Otoh, this should fix the file:// URL format we currently mishandle, so
is probably worth doing.
* What to do with non-URL (i.e. pathname) addresses?
Perhaps WinInet can handle these, but assuming it does, is there a good
reason to change from using NetIO_File()?
There are also some associated UI issues, in that we give no clue that a
pathname is acceptable as a download site, and pathnames and file://
URLs are presented terribly in the download site list.
More information about the Cygwin-apps
mailing list