From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1830 invoked by alias); 3 May 2017 16:37:29 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 909 invoked by uid 89); 3 May 2017 16:37:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Hx-languages-length:1712, site, Hx-spam-relays-external:ESMTPA, HContent-Transfer-Encoding:8bit X-HELO: out4-smtp.messagingengine.com Received: from out4-smtp.messagingengine.com (HELO out4-smtp.messagingengine.com) (66.111.4.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 May 2017 16:37:28 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3885F20AAE; Wed, 3 May 2017 12:37:29 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 03 May 2017 12:37:29 -0400 X-ME-Sender: Received: from [192.168.1.102] (host31-51-207-210.range31-51.btcentralplus.com [31.51.207.210]) by mail.messagingengine.com (Postfix) with ESMTPA id C4D297E59A; Wed, 3 May 2017 12:37:28 -0400 (EDT) Subject: Re: [PATCH setup 11/11] Use wininet for fetching URLs in direct (non-proxy) case (DO NOT APPLY) References: <20170428121205.12240-1-jon.turney@dronecode.org.uk> <20170428121205.12240-12-jon.turney@dronecode.org.uk> <3d79b33e-e067-c1df-9b90-084fb10dd272@dronecode.org.uk> <9452ab7f-986c-2394-8c24-6208e042787e@dronecode.org.uk> <506da115-b976-fdb2-bf1b-cec6addfbbbb@dronecode.org.uk> <0b6ab083-d470-c940-5557-d33be5c523cb@gmail.com> <664411e6-ac32-ab77-1b62-72bafc8bacd8@dronecode.org.uk> From: Jon Turney To: cygwin-apps@cygwin.com Cc: =?UTF-8?Q?=c3=85ke_Rehnman?= Message-ID: Date: Wed, 03 May 2017 16:37:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2017-05/txt/msg00029.txt.bz2 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.