Re: More flexible URL file name generation
Hrvoje Niksic wrote: This patch makes URL file name generation a bit more flexible and, hopefully, better for the end-user. Hi Hrvoje, I've tried out that patch under Linux. To be precisely I used the complete source code from Heiko Herold's website which had this patch already incorporated. I have used it a few days now for all my normal downloads and so far all local filenames came out correctly again. Thanks for making these changes, this makes the current version usuable for me. Jochen Roderburg ZAIK/RRZK University of Cologne Robert-Koch-Str. 10 Tel.: +49-221/478-7024 D-50931 Koeln E-Mail: [EMAIL PROTECTED] Germany
Re: mirror
Hi, On Thu, Sep 18, 2003 at 01:31:35PM +0200, Thijs Thiessens wrote: Hey! How can I mirror a small ftp location using wget? I want to sync the ftp location with a local location. Or is it better to use another program? man wget is your friend. hint: wget -np -m ftp://your.server.com/location/ -- Ryan Underwood, nemesis at icequake.net, icq=10317253
Re: non-recursion
Doug Kaufman [EMAIL PROTECTED] writes: On Thu, 18 Sep 2003, Hrvoje Niksic wrote: modifying advance_declaration() in html-parse.c. A future version of Wget will probably parse comments in a non-compliant fashion, by considering everything between !-- and -- to be a comment, which is what most other browsers have been doing since the beginnings of the web. The lynx browser is configurable as to how it parses comments. So is Wget, as of last night. The default is minimal (non-compliant) comment parsing, and that can be changed with `--strict-comments'. It can change on the fly from minimal comments to historical comments to valid comments. Which browsers act in non-compliant fashion all the time? Those that display http://www.hro.org/docs/rlex/uk/index.htm (unless I'm mistaken), and that would mean pretty much all of them. Of course, that page is but one example out of many. Some browsers have more complex heuristics for comment parsing, but adding that to Wget would probably be overdoing it.
Problem with -k and -O name parameters
Hi A problem seems to appear if we use -k and -O name parameters. Wget change the name of the file then try to convert the old name file and didn't find the file. Cordialement Sandro FERRAND
Read error (Success) in headers using wget and ssl
Hi, I'm having trouble connecting with wget to a site using SSL: wget https://145.222.135.165/index.htm --13:46:36-- https://145.222.135.165/index.htm = `index.htm' Connecting to 145.222.135.165:443... connected. HTTP request sent, awaiting response... Read error (Success) in headers. Retrying. --13:46:37-- https://145.222.135.165/index.htm (try: 2) = `index.htm' Connecting to 145.222.135.165:443... connected. HTTP request sent, awaiting response... Read error (Success) in headers. Retrying. --- Expected: Unable to establish SSL connection. because it's using client certificates, but when using the client certificate the same error occurs, so this doesn't seem a clientcertificate problem, thought it might be that wget is having trouble checking that it does need a client certificate ?! Ofcourse using IE as a browser (and the client certificate), no problem... Any idea how to fix this ? I used wget 1.8.2 and a nightly cvs of 20030909, same problem (Please reply directly too as I'm not on the list) Best regards, Dimitri
Re: Read error (Success) in headers using wget and ssl
Dimitri Ars [EMAIL PROTECTED] writes: I'm having trouble connecting with wget to a site using SSL: [...] I can repeat this, but currently I don't understand enough about SSL to fix it. Christian, could you please help? wget https://145.222.135.165/index.htm --13:46:36-- https://145.222.135.165/index.htm = `index.htm' Connecting to 145.222.135.165:443... connected. HTTP request sent, awaiting response... Read error (Success) in headers. Retrying. --13:46:37-- https://145.222.135.165/index.htm (try: 2) = `index.htm' Connecting to 145.222.135.165:443... connected. HTTP request sent, awaiting response... Read error (Success) in headers. Retrying. --- Expected: Unable to establish SSL connection. because it's using client certificates, but when using the client certificate the same error occurs, so this doesn't seem a clientcertificate problem, thought it might be that wget is having trouble checking that it does need a client certificate ?! Ofcourse using IE as a browser (and the client certificate), no problem... Any idea how to fix this ? I used wget 1.8.2 and a nightly cvs of 20030909, same problem (Please reply directly too as I'm not on the list) Best regards, Dimitri
Re: Read error (Success) in headers using wget and ssl
On Fri, 19 Sep 2003, Hrvoje Niksic wrote: wget https://145.222.135.165/index.htm --13:46:36-- https://145.222.135.165/index.htm = `index.htm' Connecting to 145.222.135.165:443... connected. HTTP request sent, awaiting response... Read error (Success) in headers. Retrying. --13:46:37-- https://145.222.135.165/index.htm (try: 2) = `index.htm' Connecting to 145.222.135.165:443... connected. HTTP request sent, awaiting response... Read error (Success) in headers. Retrying. --- Expected: Unable to establish SSL connection. because it's using client certificates, but when using the client certificate the same error occurs, so this doesn't seem a clientcertificate problem, thought it might be that wget is having trouble checking that it does need a client certificate ?! The problem seems to be a bad server certificate, or at least one not in the usual database of trusted certificates. When I connect with openssl s_client I get error:num=20 (unable to get local certificate) and also error:num=27 (certificate not trusted). The text from the server certificate follows: Certificate: Data: Version: 3 (0x2) Serial Number: 47:f7:ee:c0:35:19:65:6c:f2:16:ac:67:ae:e6:48:2e Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority Validity Not Before: Aug 26 00:00:00 2003 GMT Not After : Aug 25 23:59:59 2004 GMT Subject: C=NL, ST=Utrecht, L=Amersfoort, O=bouwfonds hypotheken, OU=Informatie Management, OU=Terms of use at pki.pinkroccade.com/rpa (c) 02, OU=Authenticated by PinkRoccade, OU=Member, VeriSign Trust Network, CN=www.bouwfondsbbs.nl Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:bd:53:94:ec:57:e7:68:05:cf:53:5e:88:24:63: ca:07:3c:0d:63:df:73:20:5c:20:37:76:e4:9c:89: eb:76:bb:55:de:41:3f:12:5f:cb:b8:fb:23:ac:7b: 48:00:50:55:51:18:cc:df:bd:62:67:85:9c:4f:99: b6:db:e0:56:e0:ab:38:33:ae:15:0d:b4:a5:c3:77: f1:1a:91:f1:15:55:14:e5:f3:7b:65:56:38:cf:ef: 4e:3a:3c:23:8a:ce:83:6b:e4:06:55:fe:ca:09:39: 25:a0:54:28:84:16:1f:12:14:ad:12:ee:05:23:e2: b7:bd:e5:73:2b:cd:85:22:11 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Key Encipherment X509v3 CRL Distribution Points: URI:http://crl.verisign.com/RSASecureServer.crl X509v3 Certificate Policies: Policy: 2.16.840.1.113733.1.7.1.1 CPS: https://www.verisign.com/CPS User Notice: Organization: VeriSign, Inc. Number: 1 Explicit Text: VeriSign's CPS incorp. by reference liab. ltd. (c)97 VeriSign X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication Authority Information Access: OCSP - URI:http://ocsp.verisign.com Signature Algorithm: sha1WithRSAEncryption 1d:46:35:f6:53:80:e8:39:1f:ff:ca:f5:7d:fd:64:06:7b:76: 78:44:1e:d3:0a:59:c5:af:2d:fe:41:19:c8:d2:db:a0:9a:8a: c6:65:87:49:ad:c0:cd:d1:b5:e6:66:c7:ac:f6:88:f5:dd:84: 58:fb:9c:d3:93:e5:81:74:99:29:90:a6:3d:40:23:7a:11:97: 60:2f:65:44:b8:33:9d:54:56:58:8f:2b:fb:c3:1c:28:7f:15: ef:aa:fa:33:ba:12:1f:d8:82:89:8d:f0:a0:f7:a5:e1:b7:05: 40:91:b3:71:a8:b1:cf:e3:2a:7b:05:89:f2:99:19:e7:cb Doug -- Doug Kaufman Internet: [EMAIL PROTECTED]
