Hi,
It is still an issue that wget/openssl combo is broken in windows. Wget source
has changed to file descriptors for sending and receiving data in windows.
OpenSSL in windows expects a socket that it can recv/send. From OpenSSL's
e_os.h
for WINDOWS:
#define
The bug (?) -- running
wget -m -np -nv \
http://sourceforge.net/projects/biblatex-biber/files/biblatex-biber/current/
ends up downloading many things above that directory, despite the -np.
Doesn't that seem wrong?
This is with wget 1.12 compiled from the original source.
The request: does
(03/30/2011 02:37 PM), Karl Berry wrote:
The bug (?) -- running
wget -m -np -nv \
http://sourceforge.net/projects/biblatex-biber/files/biblatex-biber/current/
ends up downloading many things above that directory, despite the -np.
Doesn't that seem wrong?
This is with wget 1.12 compiled
Thanks Tony.
I wonder if it's possible that that file is a redirection from a
correct URL. Because wget would expect to download all URLs from a
redirection, and would use the redirected name (but AIUI the current dev
sources wouldn't use that name without --trust-server-name or something).
In
Micah Cowan mi...@cowan.name writes:
So it looks like wget is correctly blocking the http URL, but
incorrectly permitting the https URL.
We check if the two schemes are similar but at the same time we require
the port to be identical.
I have relaxed this condition, now the two ports must be
