This is the mail archive of the
cygwin-apps
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 03/05/2017 18:08, Åke Rehnman wrote:
On 2017-05-03 18:37, Jon Turney wrote:
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.
Yea, I know, I tested a few different solutions but it was difficult to
make something clean and proper.
Ok.
* 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.
I don't know how that could have ever worked... (or does it?)
Not really, see the other branch of this thread.
* 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()?
No. WinInet need proper file://host/path syntax. But the patch I made
send those unknown protocols to NetIO_File(), right?
Yes.
I'll add a comment that "URLs we can't parse are assumed to be paths"
and apply this, after I've released 2.878.
Thanks for working on this.
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.
I saw that. Perhaps fixing that is another patch?
Sure. I just mention that for completeness, not out of any expectation
it's going to get fixed :)