Re: wget LFS patch

You are right, the 1.10 alpha1 version work with a ftp server. I noticed that my
webserver, apache 1.3.33-4 (Debian), seems to create some sort of problem with
the file length sent at the beginning of the transfer.

It looks like 1.9.1 and 1.10 alpha1 handles this case differently, which makes
it work on 1.9.1 (with my modification) and not on 1.10.

In fact, 1.9.1 (with my modification) tells, with apache 1 server :
Length: unspecified [text/plain]

when 1.10 alpha tells :
Length: -1,761,980,360 [text/plain]
(2^32-1761980360 = 2532986936)
It looks like a 64 bits value or a 32 bits unsigned interpreted as a 32 bits
signed.

On a ftp server, both clients (1.9.1 modified and 1.10 alpha1) work.
(FTP server Version 6.4/OpenBSD/Linux-ftpd-0.17)
Length: 2,532,986,936 (2.4G) (unauthoritative)


It looks like the HTTP problem is server side : I tried Mozilla 1.7.6-1 on the
same webserver, and the file length is also negative (like wget 1.10 alpha1).
(Mozilla works well with the FTP server, also like wget 1.10 alpha).


I just tried installing apache 2, hoping it has LFS support, but it doesn't
support it (apache2-2.0.53).

Do you know a webserver with good LFS support ?


* Jim Wright ([email protected]) wrote:
> Second release of alpha1 works fine for me:
> 
> % wg/wget-1.10-alpha1/src/wget http://bob/~jwright/2004-logs.tar
> --14:18:56--  http://bob/%7Ejwright/2004-logs.tar
>            => `2004-logs.tar'
> Resolving bob... 10.234.86.120
> Connecting to bob|10.234.86.120|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 2,532,986,880 (2.4G) [application/x-tar]
> 
> 100%[===========================================>] 2,532,986,880   11.12M/s    ETA 00:00
> 
> 14:22:38 (10.98 MB/s) - `2004-logs.tar' saved [2532986880/2532986880]
> 
> It works on both Suse 9.1 and Solaris 9:
> 
> % uname -a
> Linux hiki 2.6.5-7.151-default #1 Fri Mar 18 11:31:21 UTC 2005 i686 i686 i386 GNU/Linux
> % uname -a
> SunOS pbo 5.9 Generic_117171-05 sun4u sparc SUNW,Ultra-4 Solaris
> 
> Could it be your http server is not LFS capable?
> 
> Jim
> 
> 
> On Tue, 5 Apr 2005, Mathieu Desnoyers wrote:
> 
> > * Mauro Tortonesi ([email protected]) wrote:
> > > On Tuesday 05 April 2005 12:50 am, you wrote:
> > > 
> > > are you sure? LFS support has been recently integrated in wget and seems to 
> > > work pretty well. 
> > > 
> > > could you please try the 1.10-alpha1 tarball:
> > > 
> > > ftp://ftp.deepspace6.net/pub/ds6/sources/wget/wget-1.10-alpha1.tar.gz
> > > ftp://ftp.deepspace6.net/pub/ds6/sources/wget/wget-1.10-alpha1.tar.bz2
> > > 
> > > and post a report on the LFS-related faults you experience? 
> > > 
> > > thank you very much for your help.
> > > 
> > 
> > I just tried it on a local http apache webserver, and here is the result :
> > 
> > 
> > [compudj@compubox:/tmp]$ /home/compudj/local/bin/wget http://compubox/~compudj/bigfile
> > --16:01:23--  http://compubox/%7Ecompudj/bigfile
> >            => `bigfile'
> > Resolving compubox... 10.1.0.2
> > Connecting to compubox|10.1.0.2|:80... connected.
> > HTTP request sent, awaiting response... 200 OK
> > Length: -702,479,360 [text/plain]
> > 
> >     [ <=>                                 ] 0             --.--K/s             
> > 
> > 16:01:23 (0.00 B/s) - `bigfile' saved [0/-702479360])
> > 
> > 
> > Here is the real file :
> > 
> > -rw-rw-r--    1 compudj compudj 3.4G Apr  5 00:30 bigfile
> > 
> > 
> > It works well with my version. Seems like you have some long types that should
> > be changed to long long.
> > 
> > 
> > OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
> > Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 
> > 
OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68