--http-user=username --http-passwd=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
intainer, Mauro
> Tortonesi - thanks Mauro!)
>
Hurrah, 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
t-disposition (again ;-) and redirection. Often wget somehow
"loses" the Content-Length information and keeps on downloading "ad infinitum".
I did not yet try to research it in detail, but help me with
no-content-disposition and -O to set the file-name, which always w
anticipated release ;-)
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
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 doe
ol: max-age=1800
Expires: Tue, 25 Dec 2007 18:19:32 GMT
Vary: Accept-Encoding,User-Agent
Connection: 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
Zitat von Alan Watt <[EMAIL PROTECTED]>:
> The way this particular FTP proxy works, assuming the following:
>
> proxy user name: phred
> proxy user passwd: xyzzy
> proxy server IP: 169.254.1.1
> remote FTP user: sherlock
> remote FTP passwd: holmes
> remote FTP server IP: 30.1
after login the FTP-client does a normal FTP session 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
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
> >
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
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 f
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
>
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
ocal proxy is in between,
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
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.
Ano
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. Perhaps the correction is
as easy as adding the '-c' case to those options that need
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 proble
variables for the display of the progress bar are correctly
adjusted to this situation. I'll keep on trying ;-)
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED]
Germany
http.c.diff
Description: Binary data
ded and more
HEAD requests were made I really noticed it. I remember that it had always been
more difficult to get 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
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.
> >
&
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 "ti
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 n
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"
http://www.eudora.com/cgi-bin/export.
ved [9131]
ls -l index.html
-rw-r- 1 a0045 RRZK 9131 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
ee what happens in the case where 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
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.
> >
> >
gs 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
http-passwd 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.
Joche
> 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. 10
u.org page. And many 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
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 th
CTED]>
Betreff: Re: 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 diff
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
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
last public beta 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 Co
double username" to wget, either in
the URL or with the "ftp-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
real ftp-host then when you use the Solaris ftp client?
If it is something simple like login with "[EMAIL PROTECTED]" 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 Tel.: +49-221/478-7024
D-50931 Koeln E-Mail: [EMAIL PROTECTED]
Germany
only the
dialog with the proxy server and not the dialgo with the ftp server in the
background.
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
Zitat von Jean-Philippe BATTU <[EMAIL PROTECTED]>:
> Thanks for your reply but when I use
>
> wget http://myserver.com/myfile.jpg
> and
> wget -N http://myserver.com/myfile.jpg
> wget --timestamping http://myserver.com/myfile.jpg
>
> and i get the same result and the current date !
>
Sorry, I had
file, 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
0 GMT
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-St
igger than 4GB
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 d
s needed for partial transfers.
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 Te
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
lder one.
Btw, a quick work-around is to download it a second time, 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
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
checki
Zitat von Mauro Tortonesi <[EMAIL PROTECTED]>:
> >
> > The timestamping issues I reported in above mentioned message are now also
> > repaired by the patch you mailed last week here.
> > Only the small *cosmetic* issue remains that it *always* says:
> >Remote file is newer, retrieving.
> > eve
Johan Kohler 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 mymachine:~$ wget -c
>
ftp://
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 wit
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 B&W.txt came with the
> header:
> > Content-Disposition: attachment; filename=B&W.txt;
> > All prog
txt;
All programs I tried (the new wget and several browsers and my own script ;-)
seemed to stop parsing at the first semicolon and produced the filename B&.
Any thoughts ??
Best Regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-
st case:
HTTP HEAD
and says:
local_file is: index.html (existing)
which is correct now.
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 opti
Hmm, this did not actually try to write over 'index.html', did it ;-)
Do the same with 'timestamping on' and you get
(not surprisingly and with 'all' wget versions I have around) :
index.html: Permission denied
Cannot write to `index.html' (Permission denied).
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 p
Massimo Cora' schrieb:
while trying to download the latest Suse 9.3 dvd iso [about 4.2 Gb] I
got the following error:
Length: 4,488,353,792 (4.2G), 193,386,497 (184M) remaining
95% [+ ] 4,294,967,295 --.--K/s
File size limit exceeded
I'm using
[
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
(se
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
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
wget, which is already
corrected in the 1.9 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 rega
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 D
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, w
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
> >
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 u
should 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
corporated.
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.:
?
That was the main reason for me that I never started using that version ;-)
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
ers 0-31 (controls), and chars
> 128-159 (non-printable).
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.:
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-Ko
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 ca
>= 1.7. I usually then went back to a version 1.6, which I have
kept for this and other special cases, 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
an the newer one.
I do not yet use 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
BookMarx (v1). Unfortunately
this program version stopped working in the year 2000 (severe Y2k problems).
There is now a new version 2, but it is completely different and I could not
figure out how to get it to work. Nevertheless it can be found on
http://www.trellian.com/bwolf/index.html
Hi,
This release 1.81. has still the problem (bug/feature ?), that *unsafe*
characters are hex-encoded in local filenames.
Any plans to repair this ?
Best regards and a happy new year,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478
ay if this a severe problem for everybody,
at least for me the program is not usable in the present form, and I have
stopped my testing of this version meanwhile.
Unfortunately this is still the case with the 1.8 'release version' of
today, which I just downloaded and tried.
Best regards,
y_9.csv'
> >
Do I understand you right? You mean it is a new feature of the wget version
1.8 that the brackets are now promoted to 'unsafe characters' ?
Regards,
Jochen Roderburg
ZAIK/RRZK
University of Cologne
Robert-Koch-Str. 10Tel.: +49-221/478-7024
21:40:51-- 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/
Hello Hrvoje,
>
> > I think the 'timestamping' is the point, because without that I see
> > that no .listing file is used at all, and the problem doesn't
> > appear.
>
> Yes, with the timestamping turned on, I was able to repeat the
> problem. This patch should fix it:
>
> 2001-12-02 Hrvoje
and replaced by that directory.
This behaviour is still present in the second beta.
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
82 matches
Mail list logo
