=password http://rs60tl.rapidshare.com/
It *does* work for me in this form with other servers ;-)
Best regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED
, hurrah, congratulations ;-)
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED]
Germany
to research it in detail, but help me with
no-content-disposition and -O to set the file-name, which always works.
Best Regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED
: close
Content-Type: text/html
---response end---
200 OK
Length: unspecified [text/html]
[ = ] 27.556--.--K/s
Closed fd 760
18:49:25 (353.44 KB/s) - `index.html' saved [27556]
Best regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch
Zitat von Jochen Roderburg [EMAIL PROTECTED]:
What do you mean e.g. with wget interlog one ?
Hmm, googled for wget interlog and found a veery old Windows version 1.5.3
from 1999 there, which indeed gets a 404 Error from your host.
I think the server does not like the request header
Host
with the FTP-proxy.
Best regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10 Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED]
Germany
Zitat von Micah Cowan [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Micah Cowan wrote:
Jochen Roderburg wrote:
Unfortunately, however, a new regression crept in:
In the case timestamping=on, content-disposition=off, no local file
present it
does now no HEAD
Zitat von Micah Cowan [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jochen Roderburg wrote:
Zitat von Micah Cowan [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jochen Roderburg wrote:
Yes, this one is still open, and the other one
Zitat von Micah Cowan [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jochen Roderburg wrote:
And now, for a change, a case, that works now (better) ;-)
This is an example where a HEAD request gets a 500 Error response.
Wget default options again
Zitat von Micah Cowan [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jochen Roderburg wrote:
(abbreviated:)
51% [= ] 157,962
5.37K/s in 3m 45s
Further examination of such cases showed that a Byte-Range
Zitat von Micah Cowan [EMAIL PROTECTED]:
The problem you pointed out that causes the failure to properly
timestamp when HEADs aren't issued seems, to my reading, to be simply
regressable for the fix. Mauro's fixes don't look as if they depend upon
that line being there, but I'm waiting for
Zitat von Micah Cowan [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jochen Roderburg wrote:
Yes, this one is still open, and the other one that wget -c always starts
at 0
again.
Do you mean the (local 0) thing? That should have been fixed in
674cc935f7c8
,
it can happen that every HTTP-request lands on a different host with possibly
different behaviour and it can happen that we have another case of a
discrepancy between the result of a HEAD and a later GET.
Best regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10
Zitat von Jochen Roderburg [EMAIL PROTECTED]:
Continued download (wget -c) is not done in the current svn version with
default
options (where no HEAD is used). The download starts instead at byte 0 again.
When other options require a HEAD, it works ok again.
Another astonishing test result
a newer file downloaded through the proxy-cache when a
local file was present, but as these cases were rare, I had never tried to
investigate this before ;-)
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
D-50931 Koeln
Zitat von Micah Cowan [EMAIL PROTECTED]:
Btw, continued downloads (wget -c) are also
broken now in this case (probably for the same reason).
Really? I've been using this Wget version for a bit, and haven't noticed
this problem. Could you give an invocation that produces this problem?
Zitat von Micah Cowan [EMAIL PROTECTED]:
Zitat von Jochen Roderburg [EMAIL PROTECTED]:
So it looks now to me, that the new error (local timestamp not set to
remote)
only occurs in the cases when no HEAD is used.
This (new) piece of code in http.c (line 2666 ff.) looks very suspicious
Zitat von Jochen Roderburg [EMAIL PROTECTED]:
So it looks now to me, that the new error (local timestamp not set to remote)
only occurs in the cases when no HEAD is used.
This (new) piece of code in http.c (line 2666 ff.) looks very suspicious to me,
especially the time_came_from_head bit
03.09.2007 13:45 index.html
date
Mon Sep 3 13:45:24 CEST 2007
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10 Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED]
Germany
And now, for a change, a case, that works now (better) ;-)
This is an example where a HEAD request gets a 500 Error response.
Wget default options again, but contentdisposition=yes to force a HEAD.
wget.111-svn-0709 --debug -e contentdisposition = yes
And now, finally, the ultimate real-life test with proxy-cache, timestamping and
contentdisposition, where HEAD and GET have different timestamps.
And this is perfectly correct now !
So it looks now to me, that the new error (local timestamp not set to remote)
only occurs in the cases when
the two are different, this can not
easily be constructed, must way till such a case just comes along ;-)
Best Regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED
Zitat von Mauro Tortonesi [EMAIL PROTECTED]:
here is a table resuming the behaviour of current wget version (soon to be
1.11) and wget 1.10.2 regarding HTTP HEAD requests. i hope the table will be
useful to determine whether the currently implemented logic is correct.
Sorry, this huge
Zitat von Micah Cowan [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jochen Roderburg wrote:
I have tried out again the current wget version from svn to see the
progress on
various discussed problems.
Someone recently reported an inability to specify the prefix
and recent mails that there is now an option for it
which is off as default.
Best Regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED]
Germany
and --proxy-passwd command switches have
been renamed to --http-password and --proxy-password respectively, and
the related http_passwd and proxy_passwd .wgetrc commands to
http_password and proxy_password respectively. The login and passwd
.wgetrc commands have been deprecated.
Jochen Roderburg
ZAIK
external references pointed to it.
See also Mauro's last words about it:
http://www.mail-archive.com/wget@sunsite.dk/msg09567.html
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL
Zitat von Micah Cowan [EMAIL PROTECTED]:
Must be just in the README. Anywhere else that anyone knows of, speak up!
:)
wget.sunsite.dk is also mentioned in the wget FAQ
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
D
Separately resent to the list because of mistyped address ;-)
- Weitergeleitete Nachricht von Jochen Roderburg [EMAIL PROTECTED]
-
Datum: Sun, 08 Jul 2007 14:11:24 +0200
Von: Jochen Roderburg [EMAIL PROTECTED]
Antwort an: Jochen Roderburg [EMAIL PROTECTED]
Betreff: Re: fix
Separately resent to the list because of mistyped address ;-)
- Weitergeleitete Nachricht von Jochen Roderburg [EMAIL PROTECTED]
-
Datum: Sun, 08 Jul 2007 16:22:59 +0200
Von: Jochen Roderburg [EMAIL PROTECTED]
Antwort an: Jochen Roderburg [EMAIL PROTECTED]
Betreff: Re: fix
: fix: don't send HEAD if -O is given
An: Jochen Roderburg [EMAIL PROTECTED]
On Sun, 08 Jul 2007 16:22:59 +0200
Jochen Roderburg [EMAIL PROTECTED] wrote:
Zitat von Jochen Roderburg [EMAIL PROTECTED]:
So the little difference was that this version did a (IMHO) unnecessary HEAD
request
Zitat von Mauro Tortonesi [EMAIL PROTECTED]:
On Sun, 08 Jul 2007 16:22:59 +0200
Jochen Roderburg [EMAIL PROTECTED] wrote:
I think I remember now the motivation for this unnecessary HEAD request.
It *is* necessary as part of the support for getting the filename from the
Content
in 08/2006, which
so far are still there.
Ref.:
http://www.mail-archive.com/wget@sunsite.dk/msg09302.html
http://www.mail-archive.com/wget@sunsite.dk/msg09303.html
http://www.mail-archive.com/wget@sunsite.dk/msg09312.html
Best regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert
-user parameter (commandline or wgetrc). But then you
will also need two passwords, how are these entered in your ftp-client?
Perhaps you can mail a complete dialog with your ftp-client. If possible also in
a debug mode where the internal commands are shown.
Jochen Roderburg
ZAIK/RRZK
University
] then it should be
possible with wget also (without mentioning a proxy to wget). If it is some
special internal mechanism, however, then I fear it will not be possible with
wget (because it only knows the http-proxy type).
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10
regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED]
Germany
, like tar(1) do as
default and scp(1) -p do
timestamping is the magic phrase to look for ;-)
Best regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10 Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED]
Germany
Client-Date: Fri, 15 Sep 2006 12:58:14 GMT
Client-Response-Num: 1
My own experience is that the 1.11 alpha/beta versions (where this
feature was introduced) worked fine with the examples I encountered.
Best regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10
.
Maybe a run with wget debug option (-d) shows more.
I tried a visit to the mentioned site, but got only unknown host.
Is streamlib.pan.eu the real hostname?
Best regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10 Tel.: +49-221/478-7024
D-50931 Koeln
An: Jochen Roderburg [EMAIL PROTECTED]
Thanks for answer, it helped me to find out the reason.
In Wget it looks that this server supports REST command, see samples
below.
For files under 4G it works fine, over 4G it does'nt.
The server itself doesn't accept value over 4GB (2^32
Zitat von Jochen Roderburg [EMAIL PROTECTED]:
In the time-stamping mode wget always issued first a HEAD request when there
was
a local file, and later a GET request when after inspecting the HEAD outpout
it
found out that it should do so.
The wget 1.11 now *always* does the HEAD request
There seems to a configure problem with the options to specify the directories
where the SSL installation resides.
I have the SSL that I want in /usr/local and in wget 1.10.2 the configure option
--with-libssl-prefix=/usr/local worked.
Part of configure output:
checking for libssl... yes
, the cache has now the
newer file with newer file data, wget requests it new because it now sees the
local file as older, the file is retrieved directly from the cache and gets the
correct time-stamp now ;-)
Best regards,
Jochen Roderburg
Johan Kohler kohlerj at ukzn.ac.za writes:
I'm trying to d/l a dvd image via ftp. It was going quite well yesterday
The lenght is reported as negative presumably because of the large size
3.4 Gb. Is it the negative size that caused the resume to fail?
me at mymachine:~$ wget -c
Zitat von Jochen Roderburg [EMAIL PROTECTED]:
Zitat von Hrvoje Niksic [EMAIL PROTECTED]:
Mauro, you will need to look at this one. Part of the problem is that
Wget decides to save to index.html.1 although -c is in use. That is
solved with the patch attached below. But the other part
Zitat von Hrvoje Niksic [EMAIL PROTECTED]:
Mauro, you will need to look at this one. Part of the problem is that
Wget decides to save to index.html.1 although -c is in use. That is
solved with the patch attached below. But the other part is that
hstat.local_file is a NULL pointer when
Zitat von Hrvoje Niksic [EMAIL PROTECTED]:
Jochen Roderburg [EMAIL PROTECTED] writes:
E.g, a file which was supposed to have the name BW.txt came with the
header:
Content-Disposition: attachment; filename=Bamp;W.txt;
All programs I tried (the new wget and several browsers and my own
.
Then again it says:
Remote file is newer, retrieving.
which is wrong now, as local and remote are the same.
Then it goes ahead and downloads the file and saves it to
index.html.1, as if the timestamping option is not set at all,
wrong again.
Best Regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Zitat von Reginaldo O. Andrade [EMAIL PROTECTED]:
I would like to friendly offer a challenge to you. Can you download
something from the site www.babene.ru using wget? I always receive the
message ERROR 403: Forbidden, but using Firefox or IE, I download the
pictures without any problem. I
Herold Heiko schrieb:
I have a reproducable report (thanks Igor Andreev) about a little verbouse
log problem with ftp with my windows binary, is this reproducable on other
platforms, too ?
wget -v ftp://garbo.uwasa.fi/pc/batchutil/buf01.zip
ftp://garbo.uwasa.fi/pc/batchutil/rbatch15.zip
Zitat von Oliver Schulze L. [EMAIL PROTECTED]:
Hi Mauro,
do you know if the regex patch from Tobias was applied to this release?
Thanks
Oliver
The last words on this topic that I remember were here:
http://www.mail-archive.com/wget@sunsite.dk/msg07436.html
Regards,
J.Roderburg
Zitat von Oliver Schulze L. [EMAIL PROTECTED]:
Neither, rc1 or alpha2 have prce patch included.
I think that prce is a very usefull patch, and it should be
added to CVS and not enabled by default in the ./configure script.
So, if you want to use prce, just ./configure --with-prce
and
versions.
Regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10 Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED]
Germany
Zitat von Graham Leggett [EMAIL PROTECTED]:
In v1.9.1 of wget, it is not possible to retrieve files from an ftp
server that requires a username and password.
Hmm, worked always fine here (anonymous and non-anonymous) with
ftp://user:[EMAIL PROTECTED]/path-to-file
Best regards,
Jochen
none none wrote:
$ wget -S --referer=http://5.6.7.8/index.htm \
--user-agent=Mozilla \
http://1.2.3.4/?.file
--00:00:00-- http://1.2.3.4/%E9.file
= `?.file'
Connecting to 1.2.3.4:80... connected.
HTTP request sent, awaiting response...
1 HTTP/1.1 403 Forbidden
2
Zitat von Daniel Daboul [EMAIL PROTECTED]:
On Tue, Dec 09, 2003 at 11:30:54PM +0100, Hrvoje Niksic wrote:
You're not making a mistake, recursive download over FTP proxies is
currently broken.
That is probably the single feature I'd want most. Is there an older
version of wget, where it
Zitat von Hrvoje Niksic [EMAIL PROTECTED]:
Jochen Roderburg [EMAIL PROTECTED] writes:
Zitat von Hrvoje Niksic [EMAIL PROTECTED]:
It's a feature. `-A zip' means `-A zip', not `-A zip,html'. Wget
downloads the HTML files only because it absolutely has to, in order
to recurse through
be rejected.
The recursion is then done correctly.
Best Regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10 Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED]
Germany
Zitat von Hrvoje Niksic [EMAIL PROTECTED]:
It's a feature. `-A zip' means `-A zip', not `-A zip,html'. Wget
downloads the HTML files only because it absolutely has to, in order
to recurse through them. After it finds the links in them, it deletes
them.
Hmm, so it has really been an
.
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
).
I hope, you didn't really mean this.
You don't intend to encode the international characters, do you ?
Regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10 Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED
Hello Heiko,
Could you perhaps also offer a current wget version without SSL support on your
website?
For those that don't want SSL and/or don't want to fight with additional
(sometimes incompatible) DLLs ;-)
Regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10
, and this always did the continued
download without problems.
Best Regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10 Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED]
Germany
Hrvoje Niksic wrote:
Can you show me a sample URL where continued download works with 1.6,
but not with 1.8.1?
I tried to find one, and found something else instead:
The problem seems to occur only when a proxy is involved.
Therefore you can't test my example cases yourself, because
you
version 1.8.x, because this has the not yet
repaired problem with the special character translation
in local filenames ;-)
Best Regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
D-50931 Koeln E-Mail
-- http://www.polscan.hg.pl/scans/%5BGmbH%5D_Scenery_9.csv
= `%5BGmbH%5D_Scenery_9.csv'
And the local filename is indeed then %5BGmbH%5D_Scenery_9.csv
Regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
D-50931 Koeln
.
Best regards and thank you once more for this really useful utility,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED]
Germany
67 matches
Mail list logo
