This is the mail archive of the cygwin-apps mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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 toI'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 networkI'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:// URLsI'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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |