Re: cygwin wget ssl
On Wed, 20 Apr 2005, Hrvoje Niksic wrote: It seems this site is sending something that the OpenSSL library cannot handle. For example, both Wget and curl on Linux display the same error: $ curl https://www.danier.com curl: (35) error:1408F455:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac Maybe this should be reported to the OpenSSL maintainers? If you force it to do SSLv2 it works fine. At times, old and bad SSL implementations make it hard for OpenSSL to autodetect version. -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Problems with mirror option on Win XP
Ola! I encountered a problem on Win XP when I want to use -m option with wget. The command looks like this : wget -m -nH -nv -o wget.log --cut-dirs=1 --progress=bar http://IP_ADDRESS:8014/VIRTUAL_DIR Directory structure on server looks something like this and inside every directory there is one or more files: VIRTUAL_DIR |- DIR1 | |-DIR12 | |-DIR123 | |-DIR1234 | |-DIR12345 |- DIR2 When I call command for the first time, wget creates all directories and I get all the files that are inside those directories. If I add or change a file in directory DIR12 for example, the command retrieves new/changed file. BUT if I change or add a file in DIR12345, the file is not copied from server. And in the log file there is no record of wget trying to access that directory. Last scanned directory is DIR1234. If I run that same command on linux machine it works well. I even tried to run it on XP under cygwin and it works. I tried to change command to use -l option and it still doesn't work. If someone could give me any idea what is going on I would be very grateful. Thanks, Zoran
Length: -77,656,064
Hello gnu, I'm experiencing a wrong display of the file size of a huge file to get: berny wget -Y off -c 'ftp://my-server/pub/dvd.iso' --13:56:35-- ftp://my-server/pub/dvd.iso = `dvd.iso' Resolving my-server... 192.168.0.4 Connecting to linx.ct.siemens.de[192.168.0.4]:21... connected. Logging in as anonymous ... Logged in! == SYST ... done.== PWD ... done. == TYPE I ... done. == CWD /pub ... done. == PASV ... done.== RETR dvd.iso ... done. Length: -77,656,064 (unauthoritative) ... The file on the FTP-Server is 2^32 bytes: -rw-r--r-- 1 75 ftp 8512278528 Apr 13 10:31 suse93-dvd1-7.9GBImage.iso My version of wget: berny wget --version GNU Wget 1.9.1 ... My system(s): Solaris9 (SunOS 5.9) Cygwin (CYGWIN_NT-5.0 1.5.14) I think it is only a displaying error since the download starts correctly. Have a nice day, Bernhard Voelker
bugs on NTLM
Hi!
Last two days I have been learning and debugging NTLM on the latest
version of wget from cvs (1.10-alpha2+cvs-dev). Mainly I have debugged
on linux, but noticed same problems occurs on win32 too. During testing
I found four bugs, that needs to be fixed.
On previous threads I noticed that you had problem to find test server
for NTLM-testing. If you need, I can provide IIS-6.0 server for testing
NTLM. Just let me know, so I will set it up.
1:NTLM Domain is not written right
in http-ntlm.c line ~420
usr = strchr(user, '\\');
if (!usr) usr = strchr(user, '/');
if (usr) {
domain = usr; // Sets pointer to '\' or '/'. Should be: domain = user;
domlen = usr - domain;
usr++;
}
2: NTLM auth stops to early.
in http.c there is variable auth_tried_already and test
if (auth_tried_already || !(user passwd)) ...
Now when trying, wget tries first basic auth and gets back
WWW-Authenticate: NTLM
in response header. wget send first phase of authentication fine on next
request and gets result 401 and
WWW-Authenticate: NTLM TlRMT...
in response header. Now wget should send next request with NTLM type-3
message, which contains final authentication information. I made an
dirty-hack-hack-fix to get ahead on testing. Then I found next problem.
3: NTLM type-3 message might be invalid, because server sends 401 and
WWW-Authenticate: NTLM
if response header. My testserver is Microsoft-IIS/6.0.
4: Error on response header handling
Microsoft-IIS/6.0 sends actually 2 WWW-Authenticate rows in header
...
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
...
This causes that authentication scheme is never recognized.
resp_header_strdup (resp, WWW-Authenticate)
gives returns first 'WWW-Authenticate'-value and it is 'Negotiate'.
Problem do not occur on all IIS-server.
I'm newbie on taking part in open source projects, so hope these
descriptions of the problems was clear enough.
Thanks before
Sami
Re: Length: -77,656,064
Wget 1.9.1 doesn't work with large files. The soon-to-be-released 1.10 does, though. ftp://ftp.deepspace6.net/pub/ds6/sources/wget/wget-1.10-alpha2.tar.bz2
Re: bugs on NTLM
Sami Krank [EMAIL PROTECTED] writes: Last two days I have been learning and debugging NTLM on the latest version of wget from cvs (1.10-alpha2+cvs-dev). Mainly I have debugged on linux, but noticed same problems occurs on win32 too. During testing I found four bugs, that needs to be fixed. On previous threads I noticed that you had problem to find test server for NTLM-testing. If you need, I can provide IIS-6.0 server for testing NTLM. Just let me know, so I will set it up. Please do -- I'd be interested to try it out. 1:NTLM Domain is not written right in http-ntlm.c line ~420 [...] I've now installed this fix. 2: NTLM auth stops to early. in http.c there is variable auth_tried_already and test if (auth_tried_already || !(user passwd)) ... Current usage of auth_tried_already is too naive for NTLM. After getting the NTLM type 1 message we should probably *not* set it. 3: NTLM type-3 message might be invalid, because server sends 401 and WWW-Authenticate: NTLM if response header. My testserver is Microsoft-IIS/6.0. This should be tested further. 4: Error on response header handling Microsoft-IIS/6.0 sends actually 2 WWW-Authenticate rows in header I think this is easily fixed. Wget's header code can iterate over a header -- it is already done for Set-Cookie. I'm not sure what Wget should do in the general case if it receives several WWW-Authenticate headers.
Re: cygwin wget ssl
On Thu, 21 Apr 2005, Konrad Chan wrote: After browsing the openssl newsgroup per Hrvoje's suggestion, I came to a similar conclusion as well (cipher problem). However, I couldn't find instructions on how to change the cipher for wget, I tried all the different ciphers using curl but no luck, since openssl ciphers only had SSLv3. Let me repeat myself: If you force it to do SSLv2 it works fine. wget --sslprotocol=1 -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Re: cygwin wget ssl
Daniel Stenberg [EMAIL PROTECTED] writes: On Thu, 21 Apr 2005, Konrad Chan wrote: After browsing the openssl newsgroup per Hrvoje's suggestion, I came to a similar conclusion as well (cipher problem). However, I couldn't find instructions on how to change the cipher for wget, I tried all the different ciphers using curl but no luck, since openssl ciphers only had SSLv3. Let me repeat myself: If you force it to do SSLv2 it works fine. wget --sslprotocol=1 I've now noticed that the manual doesn't document *any* of the SSL options. :-( Time to fix that oversight.
Re: wget 1.10 alpha 2
On Wed, 20 Apr 2005, Hrvoje Niksic wrote: Herold Heiko [EMAIL PROTECTED] writes: I am greatly surprised. Do you really believe that Windows users outside an academic environment are proficient in using the compiler? I have never seen a home Windows installation that even contained a compiler, the only exception being ones that belonged to professional C or C++ developers. This is what Cygwin is all about. Once you open up the Cygwin bash shell, all you have to do with most source code is configure; make; make install. I am not a programmer and have been compiling programs for several years. As long as the program copiles cleanly, there shouldn't be a problem under Windows. I don't have any idea of how many Windows users would try to patch the code if it didn't compile out of the box. The very idea that a Windows user might grab source code and compile a package is strange. I don't remember ever seeing a Windows program distributed in source form. See, for example, htmldoc which converts html into a pdf file. The free version is only distributed as source code. Or see consoletelnet, distributed both as source and binary. Doug -- Doug Kaufman Internet: [EMAIL PROTECTED]
Re: wget 1.10 alpha 2
Doug Kaufman [EMAIL PROTECTED] writes: On Wed, 20 Apr 2005, Hrvoje Niksic wrote: Herold Heiko [EMAIL PROTECTED] writes: I am greatly surprised. Do you really believe that Windows users outside an academic environment are proficient in using the compiler? I have never seen a home Windows installation that even contained a compiler, the only exception being ones that belonged to professional C or C++ developers. This is what Cygwin is all about. Once you open up the Cygwin bash shell, all you have to do with most source code is configure; make; make install. Oh, I know that and I *love* Cygwin and use it all the time (while in Windows)! But that is beside the point because this problem doesn't occur under Cygwin in the first place -- Cygwin compilation is as clean as it gets. My point was that a typical Windows (not Cygwin) user doesn't know about the compilation process, nor can he be bothered to learn. That's a great shame, but it's something that's not likely to change. Making the code uglier for the sake of ordinary Windows users willing to compile it brings literally no gain. The above shouldn't be construed as not wanting to support Windows at all. There are Windows users, on this list and elsewhere, who are perfectly able and willing to compile Wget from source. But those users are also able to read the documentation, to turn off optimization for offending functions, not to mention to upgrade their compiler, or get a free one that is much less buggy (the Borland compiler comes to mind, but there are also Mingw, Cygwin, Watcom, etc.)
SSL options
I remembered why I never documented the SSL options. Because they are badly named, accept weird values, and I wanted to fix them. I felt (and still feel) that documenting them would make them official and force us to keep supporting them forever. Here is the list, extracted from `wget --help': --sslcertfile=FILE optional client certificate. --sslcertkey=KEYFILE optional keyfile for this certificate. --sslcadir=DIR dir where hash list of CA's are stored. --sslcafile=FILE file with bundle of CA's --sslcerttype=0/1 Client-Cert type 0=PEM (default) / 1=ASN1 (DER) --sslcheckcert=0/1 Check the server cert agenst given CA --sslprotocol=0-3 choose SSL protocol; 0=automatic, 1=SSLv2 2=SSLv3 3=TLSv1 --egd-file=FILEfile name of the EGD socket. The names are unreadable because they don't include the usual separator between words. They also contain weird acronyms and abbreviations, such as CA or cert, making them even harder to read. Finally, the values they force upon the user are unbelievably cryptic. How hard would it have been to support something like --sslprotocol=sslv2 or --sslcerttype=pem... but no, it was easier to call atoi. The question is what should we do for 1.10? Document the unreadable names and cryptic values, and have to support them until eternity? Leave them undocumented and fix (and document) them for the next release? Fix them for this release (and break the freeze), and document them? Does anyone ever use them anyway?
RE: SSL options
Hrvoje Niksic wrote: The question is what should we do for 1.10? Document the unreadable names and cryptic values, and have to support them until eternity? My vote is to change them to more reasonable syntax (as you suggested earlier in the note) for 1.10 and include the new syntax in the documentation. However, I think wget should to continue to support the old options and syntax as alternatives in case people have included them in scripts. Tony
404 error redirect
I'm setting up a site for my company to allow people to get certain files out of our company repository. Basically, I want people to be able to write the following: wget http://servername/~tgibbs/FileWanted.rpm However, the files are stored someplace else and I don't want to mirror them. Therefore, I have set up an ErrorDocument in apache that on 404 errors redirects to another page. The second page, then determines the referring URI and serves up the correct rpm. This works fine if I'm using internet explorer, but wget gives me a 404 error :-( For some reason, it is not following the internal redirect. Does anyone know a way around this? If not, perhaps you know of a way to tell wget how to name the file based on HTTP headers. I've tried attachement; filename="filename" but it just ignores those. Also, I'm not subscribed to the list, so please cc me. Thanks! Tanton
NTLM test server available
Hi! You may use this server to test NTLM-authentication on wget. http://212.50.205.135/ntlm/ usr: testuser pwd: DummyUser Server is not promised to be available all the time, because it is actually running under my linux workstation. Server is MS Windows Server 2003 Enterprise Edition + IIS 6.0. Hope this helps you on testing. Sami
