-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sir Vision wrote:
Hello,
enterring following command results in an error:
--- command start ---
c:\Downloads\wget_v1.11.3bwget
ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8-l10n/;
-P c:\Downloads\
--- command
Micah Cowan [EMAIL PROTECTED] writes:
The new Wget flags empty Set-Cookie as a syntax error (but only
displays it in -d mode; possibly a bug).
I'm not clear on exactly what's possibly a bug: do you mean the fact
that Wget only calls attention to it in -d mode?
That's what I meant.
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hrvoje Niksic wrote:
Generally, if Wget considers a header to be in error (and hence
ignores it), the user probably needs to know about that. After all,
it could be the symptom of a Wget bug, or of an unimplemented
extension the server
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Diego Campo wrote:
Hi,
I got a bug on wget when executing:
wget -a log -x -O search/search-1.html --verbose --wait 3
--limit-rate=20K --tries=3
http://www.nepremicnine.net/nepremicninske_agencije.html?id_regije=1
Segmentation fault (core
Micah Cowan [EMAIL PROTECTED] writes:
I was able to reproduce the problem above in the release version of
Wget; however, it appears to be working fine in the current
development version of Wget, which is expected to release soon as
version 1.11.*
I think the old Wget crashed on empty
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hrvoje Niksic wrote:
Micah Cowan [EMAIL PROTECTED] writes:
I was able to reproduce the problem above in the release version of
Wget; however, it appears to be working fine in the current
development version of Wget, which is expected to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mauro Tortonesi wrote:
Micah Cowan ha scritto:
Update of bug #20323 (project wget):
Status: Ready For Test = In
Progress
___
Follow-up Comment #3:
Daniel Richard G. ha scritto:
Hello,
The MAKEDEFS value in the top-level Makefile.in also needs to include
DESTDIR='$(DESTDIR)'.
fixed, thanks.
--
Aequam memento rebus in arduis servare mentem...
Mauro Tortonesi http://www.tortonesi.com
University of Ferrara -
Tobias Koeck wrote:
done.
== PORT ... done.== RETR SUSE-10.0-EvalDVD-i386-GM.iso ... done.
[ = ] -673,009,664 113,23K/s
Assertion failed: bytes = 0, file retr.c, line 292
This application has requested the Runtime to terminate it in an unusual
way.
Tristan Miller [EMAIL PROTECTED] writes:
There appears to be a bug in the documentation (man page, etc.) for
wget 1.9.1.
I think this is a bug in the man page generation process.
D Richard Felker III [EMAIL PROTECTED] writes:
The request log shows that the slashes are apparently respected.
I retried a test case and found the same thing -- the slashes were
respected.
OK.
Then I remembered that I was using -i. Wget seems to work fine with
the url on the command
On Mon, Mar 01, 2004 at 07:25:52PM +0100, Hrvoje Niksic wrote:
Removing the offending code fixes the problem, but I'm not sure if
this is the correct solution. I expect it would be more correct to
remove multiple slashes only before the first occurrance of ?, but
not afterwards.
D Richard Felker III [EMAIL PROTECTED] writes:
The following code in url.c makes it impossible to request urls that
contain multiple slashes in a row in their query string:
[...]
That code is removed in CVS, so multiple slashes now work correctly.
Think of something like
On Mon, Mar 01, 2004 at 03:36:55PM +0100, Hrvoje Niksic wrote:
D Richard Felker III [EMAIL PROTECTED] writes:
The following code in url.c makes it impossible to request urls that
contain multiple slashes in a row in their query string:
[...]
That code is removed in CVS, so multiple
D Richard Felker III [EMAIL PROTECTED] writes:
Think of something like http://foo/bar/redirect.cgi?http://...
wget translates this into: [...]
Which version of Wget are you using? I think even Wget 1.8.2 didn't
collapse multiple slashes in query strings, only in paths.
I was using
Dieter Drossmann [EMAIL PROTECTED] writes:
I use a extra file with a long list of http entries. I included this
file with the -i option. After 154 downloads I got an error
message: Segmentation fault.
With wget 1.7.1 everything works well.
Is there a new limit of lines?
No, there's no
Boehn, Gunnar von [EMAIL PROTECTED] writes:
I think I found a bug in wget.
You did. But I believe your subject line is slightly incorrect. Wget
handles 0 length time intervals (see the assert message), but what it
doesn't handle are negative amounts. And indeed:
gettimeofday({1063461157,
Try telnet www.sosi.cnrs.fr 80
if it connects type GET / HTTP/1.0 followed by two newlines. If you don't
get the output of the webserver you probably have a routing problem or
something else.
Heiko
--
-- PREVINET S.p.A.[EMAIL PROTECTED]
-- Via Ferretto, 1ph
Cédric Rosa wrote:
Hello,
First, scuse my english but I'm french.
When I try with wget (v 1.8.1) to download an url which is behind a router,
the software wait for ever even if I've specified a timeout.
With ethereal, I've seen that there is no response from the server (ACK
never
thanks for your help :)
I'm installing version 1.9 to check. I think this update may solve my
problem.
Cedric Rosa.
- Original Message -
From: Hack Kampbjørn [EMAIL PROTECTED]
To: Cédric Rosa [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, June 21, 2002 7:27 PM
Subject: Re: Bug
Vladimir Volovich [EMAIL PROTECTED] writes:
while downloading some file (via http) with wget 1.8, i got an error:
assertion failed: p - bp-buffer = bp-width, file progress.c, line 673
Abort (core dumped)
Thanks for the report. It's a known problem in 1.8, fixed by this
patch.
Index:
[EMAIL PROTECTED] writes:
Today I downloaded the new wget release (1.8) (I'm a huge fan of the
util btw ;p ) and have been trying out the rate-limit feature.
[...]
assertion p - bp-buffer = bp-width failed: file progress.c,
line 673
Thanks for the report. The bug shows with downloads whose
22 matches
Mail list logo
