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

[Jon Turney]

On 16/05/17 18:05, Åke Rehnman wrote:

On 2017-05-16 16:00, Jon Turney wrote:

I am a bit confused about the behaviour I'm seeing, though.

I'm expecting "file:///c:/path" and "file://host/path" to work, but
they don't seem to.

Same behavior here...


Since those are apparently the correct form of URLs, any ideas about how 
we might get them to work?



However, "file://c:/path" now works, which is good, and
"file:host/path" continues to work

The documentation for InternetOpenUrl() says "Only URLs beginning with
ftp:, http:, or https: are supported" so I'm wondering if this is
really something we should be expecting to work...

Here is at least an enumeration of different schemes...
https://msdn.microsoft.com/en-us/library/windows/desktop/aa385149(v=vs.85).aspx


Hmm...  I'm not sure that's not just telling you what you can get back 
from InternetCrackUrl (which we should probably switch to using in 
NetIO::set_url() rather than doing things by hand)



Also, is there a reason for the hunk in nio-file.cc removing the
reporting of a problem opening the file?


It will complain for every setup file not found for instance if setup.xz
is missing bug setup.ini is present. And besides, why should nio_file
complain but not http and ftp?


Ah yes, I see the inconsistency now you point it out.  Makes sense.

I guess that should be changed to a log message.

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

[Jon Turney]

On 04/05/2017 11:11, Jon Turney wrote:

On 03/05/2017 18:08, Åke Rehnman wrote:

On 2017-05-03 18:37, Jon Turney wrote:


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


So, I taking another look at this:

I am a bit confused about the behaviour I'm seeing, though.

I'm expecting "file:///c:/path" and "file://host/path" to work, but they 
don't seem to.


However, "file://c:/path" now works, which is good, and 
"file:host/path" continues to work


The documentation for InternetOpenUrl() says "Only URLs beginning with 
ftp:, http:, or https: are supported" so I'm wondering if this is really 
something we should be expecting to work...


Also, is there a reason for the hunk in nio-file.cc removing the 
reporting of a problem opening the file?

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

[Jon Turney]

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 :)

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

[Jon Turney]

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.

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

[Jon Turney]

On 03/05/2017 08:22, Brian Inglis wrote:

On 2017-05-02 05:05, Jon Turney wrote:

On 02/05/2017 08:28, Åke Rehnman wrote:

On 2017-05-01 22:45, Jon Turney wrote:

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.


URLs are like http://host/path - file://host/path; if no host is given,
localhost is assumed in http:///path and file:///path

file:/// is the local root but some browsers accept just / e.g. lynx
on Cygwin and Linux - useful to test this stuff, as GUI browsers look
up URL history for completions.
Most Windows browsers require the drive at the start of the path so
should accept file:///d|/ (HTML originally allowed ":" only after the
proto, and before the password and port in
proto://[[[user][:pswd]@]host[:port]]/path
so d| was required but that was relaxed in IE, and later other browsers
followed), so likely file:///C:/, just C:, maybe C:/, rarely or never /.


Yes.  Unfortunately, none of this works correctly in setup at the moment.

Incorrect URLs of the form 'file:server/pathname/' work in setup, 
but my attempts to construct something setup would use as a file URL for 
a local directory were unsuccessful.

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

[Brian Inglis]

On 2017-05-02 05:05, Jon Turney wrote:
> On 02/05/2017 08:28, Åke Rehnman wrote:
>> On 2017-05-01 22:45, Jon Turney wrote:
> 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.

URLs are like http://host/path - file://host/path; if no host is given, 
localhost is assumed in http:///path and file:///path

file:/// is the local root but some browsers accept just / e.g. lynx 
on Cygwin and Linux - useful to test this stuff, as GUI browsers look 
up URL history for completions. 
Most Windows browsers require the drive at the start of the path so 
should accept file:///d|/ (HTML originally allowed ":" only after the 
proto, and before the password and port in 
proto://[[[user][:pswd]@]host[:port]]/path
so d| was required but that was relaxed in IE, and later other browsers 
followed), so likely file:///C:/, just C:, maybe C:/, rarely or never /.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

[Åke Rehnman]

Hi,


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


/Ake
From 4e8a95e59bf761bc4d0bcc4ba3ec042401073b54 Mon Sep 17 00:00:00 2001
From: Ake Rehnman 
Date: Tue, 2 May 2017 20:55:07 +0200
Subject: [PATCH 1/1] Use wininet for "file://" protocol. Use NetIO_File for
 unknown protocols.

---
 netio.cc| 10 ++
 nio-file.cc |  7 ---
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/netio.cc b/netio.cc
index cf634c1..07ee217 100644
--- a/netio.cc
+++ b/netio.cc
@@ -126,7 +126,7 @@ NetIO::open (char const *url, bool cachable)
 {
   NetIO *rv = 0;
   enum
-  { http, https, ftp, ftps, file }
+  { http, https, ftp, ftps, file, unk }
   proto;
   if (strncmp (url, "http://;, 7) == 0)
 proto = http;
@@ -136,10 +136,12 @@ NetIO::open (char const *url, bool cachable)
 proto = ftp;
   else if (strncmp (url, "ftps://", 7) == 0)
 proto = ftps;
-  else
+  else if (strncmp (url, "file://", 7) == 0)
 proto = file;
+  else
+proto = unk;
 
-  if (proto == file)
+  if (proto == unk)
 rv = new NetIO_File (url);
   else if (net_method == IDC_NET_IE5)
 rv = new NetIO_IE5 (url, false, cachable);
@@ -157,7 +159,7 @@ NetIO::open (char const *url, bool cachable)
case ftp:
  rv = new NetIO_FTP (url);
  break;
-   case file:
+   case unk:
  rv = new NetIO_File (url);
  break;
default:
diff --git a/nio-file.cc b/nio-file.cc
index e69f1ff..c302616 100644
--- a/nio-file.cc
+++ b/nio-file.cc
@@ -35,13 +35,6 @@ NetIO (Purl)
 {
   file_size = get_file_size (std::string("file://") + path);
 }
-  else
-{
-  const char *err = strerror (errno);
-  if (!err)
-   err = "(unknown error)";
-  note (NULL, IDS_ERR_OPEN_READ, path, err);
-}
 }
 
 NetIO_File::~NetIO_File ()
-- 
2.12.2

Re: [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

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

[Åke Rehnman]

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.


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 
handle what ever protocols wininet has. Also letting wininet taking care 
of file:// url's would let the user install from a local network 
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.


/Ake

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

[Jon Turney]

On 01/05/2017 16:30, Åke Rehnman wrote:

Hello,

I tested with my repo and it seem to fail if there is no setup.xz but
only setup.ini. It does quickly realize there are no setup.xz and
setup.xz.sig but then it takes forever to get past setup.bz2 etc and
fails to download setup.ini

These tests were done with -X flag.


Thanks very much for testing this.

It seems this could be an existing bug which could have been triggered 
the proxy case.


The attached incremental patch fixed this for me.
From a30dab3f8c9081d922b7287801b882001077ddeb Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Mon, 1 May 2017 21:40:40 +0100
Subject: [PATCH setup] Close rather than leak InternetOpenUrl() handles with
 errors

---
 nio-ie5.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/nio-ie5.cc b/nio-ie5.cc
index 3375c04..ba19ffa 100644
--- a/nio-ie5.cc
+++ b/nio-ie5.cc
@@ -122,6 +122,7 @@ try_again:
}
  else if (type >= 300)
{
+ InternetCloseHandle (connection);
  connection = 0;
  return;
}
-- 
2.12.2

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

[Åke Rehnman]

Hello,

I tested with my repo and it seem to fail if there is no setup.xz but 
only setup.ini. It does quickly realize there are no setup.xz and 
setup.xz.sig but then it takes forever to get past setup.bz2 etc and 
fails to download setup.ini


These tests were done with -X flag.

I will email the link to the repo in a separate email.

/Ake


On 2017-05-01 14:58, Jon Turney wrote:


Anyhow, I had another go the wininet patch, attached.  I guess you 
have some use case for this, so perhaps you could give it a try and 
see if it works for you?

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

[Jon Turney]

On 29/04/2017 11:53, Jon Turney wrote:

On 28/04/2017 16:33, Åke Rehnman wrote:

On 2017-04-28 14:12, Jon Turney wrote:

From the discussion in [1], I was somewhat surprised to learn
that setup doesn't support https or ftps.

For the same exact reason I've just recently patched in curl


I'd be very interested to see that patch :)


Thanks very much for the patch.

So... I'm in two minds about this.   Your patch seems good, but perhaps 
the problems with using wininet aren't insurmountable, and avoiding 
another dependency would also be good.


Anyhow, I had another go the wininet patch, attached.  I guess you have 
some use case for this, so perhaps you could give it a try and see if it 
works for you?
From b11932cacaa1743b3dc60c149f268d767e99bf9f Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Thu, 30 Mar 2017 11:48:44 +0100
Subject: [PATCH setup] Use wininet for fetching URLs in direct (non-proxy)
 case

From the discussion in [1], I was somewhat surprised to learn that setup
doesn't support https or ftps.

Switch to using wininet for fetching URLs in the direct (non-proxy) case, as
well. (It's already used in proxy case). This allows https and ftps
protocols to be used.

For the moment, we keep around the existing, hand-built URL fetching as
'Direct (legacy)'.

Arrange for mirrors.lst and setup.ini to be cached by wininet, but not
package archives (as setup maintains it's own cache of those)

Read from wininet in chunks rather than the whole file, so we can report
progress feedback as we download.

Also fix up some bad indentation.

I think the reason we have a handbuilt HTTP client is that back in 2000 or
so, we were concerned about the case where IE5 wasn't installed and so
wininet wasn't available.  But who knows...

[1] https://cygwin.com/ml/cygwin/2017-03/msg00384.html

Signed-off-by: Jon Turney 
---
 ConnectionSetting.cc |  5 +
 geturl.cc|  8 
 net.cc   | 34 +-
 netio.cc | 34 ++
 netio.h  |  4 +++-
 nio-ie5.cc   | 33 -
 nio-ie5.h|  4 ++--
 res.rc   |  2 ++
 resource.h   |  1 +
 9 files changed, 88 insertions(+), 37 deletions(-)

diff --git a/ConnectionSetting.cc b/ConnectionSetting.cc
index 5baf76c..1154d94 100644
--- a/ConnectionSetting.cc
+++ b/ConnectionSetting.cc
@@ -49,6 +49,9 @@ ConnectionSetting::~ConnectionSetting ()
   sprintf(port_str, "%d", NetIO::net_proxy_port);
   UserSettings::instance().set("net-proxy-port", port_str);
   break;
+case IDC_NET_DIRECT_LEGACY:
+  UserSettings::instance().set("net-method", "Legacy");
+  break;
 default:
break;
 }
@@ -63,6 +66,8 @@ ConnectionSetting::typeFromString(const std::string& aType)
 return IDC_NET_IE5;
   if (!casecompare(aType, "Proxy"))
 return IDC_NET_PROXY;
+  if (!casecompare(aType, "Legacy"))
+return IDC_NET_DIRECT_LEGACY;
 
   /* A sanish default */
   return IDC_NET_IE5;
diff --git a/geturl.cc b/geturl.cc
index 17ad8e9..5abd39a 100644
--- a/geturl.cc
+++ b/geturl.cc
@@ -106,12 +106,12 @@ progress (int bytes)
 }
 
 static void
-getUrlToStream (const string &_url, io_stream *output)
+getUrlToStream (const string &_url, io_stream *output, bool cachable)
 {
   Log (LOG_BABBLE) << "getUrlToStream " << _url << endLog;
   is_local_install = (source == IDC_SOURCE_LOCALDIR);
   init_dialog (_url, 0);
-  NetIO *n = NetIO::open (_url.c_str());
+  NetIO *n = NetIO::open (_url.c_str(), cachable);
   if (!n || !n->ok ())
 {
   delete n;
@@ -153,7 +153,7 @@ get_url_to_membuf (const string &_url, HWND owner)
   try 
 {
   Log (LOG_BABBLE) << "get_url_to_membuf " << _url << endLog;
-  getUrlToStream (_url, membuf);
+  getUrlToStream (_url, membuf, true);
   
   if (membuf->seek (0, IO_SEEK_SET))
{
@@ -213,7 +213,7 @@ get_url_to_file (const string &_url,
 
   remove (_filename.c_str());  /* but ignore errors */
 
-  NetIO *n = NetIO::open (_url.c_str());
+  NetIO *n = NetIO::open (_url.c_str(), false);
   if (!n || !n->ok ())
 {
   delete n;
diff --git a/net.cc b/net.cc
index 659cf9b..903f096 100644
--- a/net.cc
+++ b/net.cc
@@ -37,30 +37,31 @@ extern ThreeBarProgressPage Progress;
 
 static StringOption ProxyOption ("", 'p', "proxy", "HTTP/FTP proxy 
(host:port)", false);
 
-static int rb[] = { IDC_NET_IE5, IDC_NET_DIRECT, IDC_NET_PROXY, 0 };
+static int rb[] = { IDC_NET_IE5, IDC_NET_DIRECT, IDC_NET_PROXY, 
IDC_NET_DIRECT_LEGACY, 0 };
 static bool doing_loading = false;
 
 void
 NetPage::CheckIfEnableNext ()
 {
-  int e = 0, p = 0, pu = 0;
+  int e = 0, p = 0;
   DWORD ButtonFlags = PSWIZB_BACK;
 
-  if (NetIO::net_method == IDC_NET_IE5)
-pu = 1;
-  if (NetIO::net_method == IDC_NET_IE5 || NetIO::net_method == IDC_NET_DIRECT)
+  if (NetIO::net_method == IDC_NET_IE5 ||
+  

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

[Jon Turney]

On 28/04/2017 16:33, Åke Rehnman wrote:

On 2017-04-28 14:12, Jon Turney wrote:

 From the discussion in [1], I was somewhat surprised to learn that setup
doesn't support https or ftps.

For the same exact reason I've just recently patched in curl


I'd be very interested to see that patch :)


Problems with this patch:

No progress feedback as we download.  We just get handed the whole
file by
wininet.

curl doesn't have this problem.

Although it swell a bit compare to the original installer, from 861kB to
3766kB.


I don't think that's a problem.

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

[Åke Rehnman]

Hi,

On 2017-04-28 14:12, Jon Turney wrote:

 From the discussion in [1], I was somewhat surprised to learn that setup
doesn't support https or ftps.

For the same exact reason I've just recently patched in curl


Problems with this patch:

No progress feedback as we download.  We just get handed the whole file by
wininet.

curl doesn't have this problem.

Although it swell a bit compare to the original installer, from 861kB to 
3766kB.


/Ake

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

[Jon Turney]

>From the discussion in [1], I was somewhat surprised to learn that setup
doesn't support https or ftps.

Switch to using wininet for fetching URLs in the direct (non-proxy) case, as
well. (It's already used in proxy case). This allows https and ftps
protocols to be used.

For the moment, we keep around the existing, hand-built URL fetching as
'Direct (legacy)'.

Problems with this patch:

No progress feedback as we download.  We just get handed the whole file by
wininet.

Files are cached by wininet.  This is good for setup.ini, as we don't fetch
it again when it hasn't changed, but bad for package archives as we end up
with two copies (one in wininet's cache and one in setup's cache).

I think the reason we have a handbuilt HTTP client is that back in 2000 or
so, we were concerned about the case where IE5 wasn't installed and so
wininet wasn't available.  But who knows...

[1] https://cygwin.com/ml/cygwin/2017-03/msg00384.html
---
 ConnectionSetting.cc |  5 +
 net.cc   | 34 +-
 netio.cc | 32 +---
 netio.h  |  2 ++
 nio-ie5.cc   | 23 ++-
 nio-ie5.h|  2 +-
 res.rc   |  2 ++
 resource.h   |  1 +
 8 files changed, 71 insertions(+), 30 deletions(-)

diff --git a/ConnectionSetting.cc b/ConnectionSetting.cc
index 5baf76c..1154d94 100644
--- a/ConnectionSetting.cc
+++ b/ConnectionSetting.cc
@@ -49,6 +49,9 @@ ConnectionSetting::~ConnectionSetting ()
   sprintf(port_str, "%d", NetIO::net_proxy_port);
   UserSettings::instance().set("net-proxy-port", port_str);
   break;
+case IDC_NET_DIRECT_LEGACY:
+  UserSettings::instance().set("net-method", "Legacy");
+  break;
 default:
break;
 }
@@ -63,6 +66,8 @@ ConnectionSetting::typeFromString(const std::string& aType)
 return IDC_NET_IE5;
   if (!casecompare(aType, "Proxy"))
 return IDC_NET_PROXY;
+  if (!casecompare(aType, "Legacy"))
+return IDC_NET_DIRECT_LEGACY;
 
   /* A sanish default */
   return IDC_NET_IE5;
diff --git a/net.cc b/net.cc
index 659cf9b..903f096 100644
--- a/net.cc
+++ b/net.cc
@@ -37,30 +37,31 @@ extern ThreeBarProgressPage Progress;
 
 static StringOption ProxyOption ("", 'p', "proxy", "HTTP/FTP proxy 
(host:port)", false);
 
-static int rb[] = { IDC_NET_IE5, IDC_NET_DIRECT, IDC_NET_PROXY, 0 };
+static int rb[] = { IDC_NET_IE5, IDC_NET_DIRECT, IDC_NET_PROXY, 
IDC_NET_DIRECT_LEGACY, 0 };
 static bool doing_loading = false;
 
 void
 NetPage::CheckIfEnableNext ()
 {
-  int e = 0, p = 0, pu = 0;
+  int e = 0, p = 0;
   DWORD ButtonFlags = PSWIZB_BACK;
 
-  if (NetIO::net_method == IDC_NET_IE5)
-pu = 1;
-  if (NetIO::net_method == IDC_NET_IE5 || NetIO::net_method == IDC_NET_DIRECT)
+  if (NetIO::net_method == IDC_NET_IE5 ||
+  NetIO::net_method == IDC_NET_DIRECT ||
+  NetIO::net_method == IDC_NET_DIRECT_LEGACY)
 e = 1;
   else if (NetIO::net_method == IDC_NET_PROXY)
 {
-  p = pu = 1;
+  p = 1;
   if (NetIO::net_proxy_host && NetIO::net_proxy_port)
-   e = 1;
+e = 1;
+}
+
+  if (e)
+{
+  // There's something in the proxy and port boxes, enable "Next".
+  ButtonFlags |= PSWIZB_NEXT;
 }
-   if (e)
-   {
-   // There's something in the proxy and port boxes, enable "Next".
-   ButtonFlags |= PSWIZB_NEXT;
-   }
 
   GetOwner ()->SetButtons (ButtonFlags);
 
@@ -131,8 +132,8 @@ NetPage::OnInit ()
 
   // Check to see if any radio buttons are selected. If not, select a default.
   if (SendMessage (GetDlgItem (IDC_NET_IE5), BM_GETCHECK, 0, 0) != BST_CHECKED
-  && SendMessage (GetDlgItem (IDC_NET_PROXY), BM_GETCHECK, 0, 0)
-!= BST_CHECKED)
+  && SendMessage (GetDlgItem (IDC_NET_PROXY), BM_GETCHECK, 0, 0) != 
BST_CHECKED
+  && SendMessage (GetDlgItem (IDC_NET_DIRECT_LEGACY), BM_GETCHECK, 0, 0) 
!= BST_CHECKED)
 SendMessage (GetDlgItem (IDC_NET_DIRECT), BM_CLICK, 0, 0);
 }
 
@@ -141,9 +142,7 @@ NetPage::OnNext ()
 {
   save_dialog (GetHWND ());
 
-  Log (LOG_PLAIN) << "net: "
-<< ((NetIO::net_method == IDC_NET_IE5) ? "IE5" :
-(NetIO::net_method == IDC_NET_DIRECT) ? "Direct" : "Proxy") << endLog;
+  Log (LOG_PLAIN) << "net: " << NetIO::net_method_name()  << endLog;
 
   Progress.SetActivateTask (WM_APP_START_SITE_INFO_DOWNLOAD);
   return IDD_INSTATUS;
@@ -170,6 +169,7 @@ NetPage::OnMessageCmd (int id, HWND hwndctl, UINT code)
 case IDC_NET_IE5:
 case IDC_NET_DIRECT:
 case IDC_NET_PROXY:
+case IDC_NET_DIRECT_LEGACY:
 case IDC_PROXY_HOST:
 case IDC_PROXY_PORT:
   save_dialog (GetHWND());
diff --git a/netio.cc b/netio.cc
index 5ec0b9a..76d0c8a 100644
--- a/netio.cc
+++ b/netio.cc
@@ -126,22 +126,28 @@ NetIO::open (char const *url)
 {
   NetIO *rv = 0;
   enum
-  { http, ftp, file }
+  { http, https, ftp, ftps, file }
   proto;
   if (strncmp (url, "http://;, 7) == 0)
 proto = http;
+  else if