RE: windows compile error
Does compile now, but I managed to produce an application error during a test run on a https site. I produced a debug build with /DDEBUG /Zi /Od /Fd /FR and produced the wget.bsc by running bscmake on all the sbr files, but I didn't yet understand how to use that one in VC++ in order to get a meaningfull stack trace and so on. The only thing I got for now is :SSLEAY32! 0023ca38()" as the breaking point. Anybody knows to to debug this beast or how to generate a working project file in order to make the source browser work ? Heiko Herold -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] -- +39-041-5907073 ph -- +39-041-5907472 fax > -Original Message- > From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 16, 2003 11:02 PM > To: Herold Heiko > Cc: List Wget (E-mail) > Subject: Re: windows compile error > > > Herold Heiko <[EMAIL PROTECTED]> writes: > > > Just a quick note, the current cvs code on windows during > compile (with > > VC++6) stops with > > > > cl /I. /DWINDOWS /D_CONSOLE /DHAVE_CONFIG_H > /DSYSTEM_WGETRC=\"wgetrc\" > > /DHAVE_SSL /nologo /MT /W0 /O2 /c utils.c > > utils.c > > utils.c(1651) : error C2520: conversion from unsigned > __int64 to double not > > implemented, use signed __int64 > > > > The culprit seems to be (in wtimer_sys_diff) > > > > #ifdef WINDOWS > > return (double)(wst1->QuadPart - wst2->QuadPart) / 1; > > #endif > > Does this patch help? > > 2003-09-16 Hrvoje Niksic <[EMAIL PROTECTED]> > > * utils.c (wtimer_sys_diff): Convert the time > difference to signed > __int64, then to double. This works around MS VC++ 6 > which can't > convert unsigned __int64 to double directly. > > Index: src/utils.c > === > RCS file: /pack/anoncvs/wget/src/utils.c,v > retrieving revision 1.54 > diff -u -r1.54 utils.c > --- src/utils.c 2003/09/15 21:14:15 1.54 > +++ src/utils.c 2003/09/16 21:01:02 > @@ -1648,7 +1648,10 @@ > #endif > > #ifdef WINDOWS > - return (double)(wst1->QuadPart - wst2->QuadPart) / 1; > + /* VC++ 6 doesn't support direct cast of uint64 to double. To work > + around this, we subtract, then convert to signed, then > finally to > + double. */ > + return (double)(signed __int64)(wst1->QuadPart - > wst2->QuadPart) / 1; > #endif > } > >
Handling of Content-Length 0
Please excuse if this bug has already been reported: In wget 1.8.1 (OS X) and 1.8.2 (cygwin) the handling of resources with content-length 0 is wrong. wget tries to read the empty content and hangs until the socket read timeout fires. (I set the timeout to different values and it exactly matches the termination of the GET). Of course this is only noticable with HTTP/1.1 server which leave the connection open and do not apply transfer-encding: chunked for empty response bodies. I imagine this should be quite easy to fix... Best Regards, Stefan
Re: windows compile error
Herold Heiko <[EMAIL PROTECTED]> writes: > Does compile now, but I managed to produce an application error during a > test run on a https site. > > I produced a debug build with /DDEBUG /Zi /Od /Fd /FR and produced the > wget.bsc by running bscmake on all the sbr files, but I didn't yet > understand how to use that one in VC++ in order to get a meaningfull stack > trace and so on. > The only thing I got for now is :SSLEAY32! 0023ca38()" as the breaking > point. It sounds like an https thing. Is the error repeatable? If so, can you repeat it an earlier CVS snapshot?
Re: Small change to print SSL version
"Christopher G. Lewis" <[EMAIL PROTECTED]> writes: > Here's a small change to print out the OpenSSL version with the -V & > --help parameters. [...] I think that "GNU Wget " should always stand for Wget's version, regardless of the libraries it has been compiled with. But if you want to see the version of libraries, why not make it clearer, e.g.: GNU Wget x.x.x (compiled with OpenSSL x.x.x) BTW can't you find out OpenSSL version by using `ldd'?
Re: Handling of Content-Length 0
Stefan Eissing <[EMAIL PROTECTED]> writes: > Of course this is only noticable with HTTP/1.1 server which leave > the connection open and do not apply transfer-encding: chunked for > empty response bodies. They may not apply chunked transfer because Wget doesn't know how to handle it. And leaving the connections open is also Wget's bug because it explicitly requests it. > I imagine this should be quite easy to fix... Yes. Patch following RSN.
Re: Small change to print SSL version
>GNU Wget x.x.x (compiled with OpenSSL x.x.x) >BTW can't you find out OpenSSL version by using `ldd'? Hi, no since the openssl lib is named libopenssl.so.0.9.7 but you do not se if it is 0.9.a or 0.9.7b and some programms complain about changed version so this information could be important. Also it is possible to have an static version of this lirary wich will not displayed by ldd. Cu Thomas Lußnig
RE: windows compile error
Repeatable, and it seems to appear with this: 2003-09-15 Hrvoje Niksic <[EMAIL PROTECTED]> * retr.c (get_contents): Reduce the buffer size to the amount of data that may pass through for one second. This prevents long sleeps when limiting bandwidth. * connect.c (connect_to_one): Reduce the socket's RCVBUF when bandwidth limitation to small values is requested. Previous checkout (checkout -D "23:30 15 sep 2003") wget works fine. I also found a public site which seems to expose the problem (at least from my machine): wget -dv https://www.shavlik.com/pHome.aspx dies after DEBUG output created by Wget 1.9-beta on Windows. --17:23:55-- https://www.shavlik.com/pHome.aspx => `www.shavlik.com/pHome.aspx' Resolving www.shavlik.com... 65.173.207.46 Caching www.shavlik.com => 65.173.207.46 Connecting to www.shavlik.com[65.173.207.46]:443... connected. Created socket 112. Releasing 009D00D0 (new refcount 1). ---request begin--- GET /pHome.aspx HTTP/1.0 User-Agent: Wget/1.9-beta Host: www.shavlik.com Accept: */* Connection: Keep-Alive Pragma: no-cache ---request end--- HTTP request sent, awaiting response... HTTP/1.1 200 OK Cache-Control: private Content-Length: 14115 Content-Type: text/html; charset=utf-8 X-Powered-By: ASP.NET X-AspNet-Version: 1.1.4322 Server: WEBSERVER Date: Wed, 17 Sep 2003 15:27:28 GMT Connection: keep-alive Found www.shavlik.com in host_name_addresses_map (009D00D0) Registered fd 112 for persistent reuse. Length: 14,115 [text/html] 0% [ ] 0 --.--K/s Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] -- +39-041-5907073 ph -- +39-041-5907472 fax > -Original Message- > From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 17, 2003 12:44 PM > To: Herold Heiko > Cc: List Wget (E-mail) > Subject: Re: windows compile error > > > Herold Heiko <[EMAIL PROTECTED]> writes: > > > Does compile now, but I managed to produce an application > error during a > > test run on a https site. > > > > I produced a debug build with /DDEBUG /Zi /Od /Fd /FR and > produced the > > wget.bsc by running bscmake on all the sbr files, but I didn't yet > > understand how to use that one in VC++ in order to get a > meaningfull stack > > trace and so on. > > The only thing I got for now is :SSLEAY32! 0023ca38()" as > the breaking > > point. > > It sounds like an https thing. > > Is the error repeatable? If so, can you repeat it an earlier CVS > snapshot? >
RE: Small change to print SSL version
Perhaps, but it is kind of nice to get that information from the program itself at the same time you get the version information. For example: # ssh -V OpenSSH_3.7p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003 All the information, from one place. Mark Post -Original Message- From: Hrvoje Niksic [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 7:15 AM To: Christopher G. Lewis Cc: [EMAIL PROTECTED] Subject: Re: Small change to print SSL version "Christopher G. Lewis" <[EMAIL PROTECTED]> writes: > Here's a small change to print out the OpenSSL version with the -V & > --help parameters. [...] I think that "GNU Wget " should always stand for Wget's version, regardless of the libraries it has been compiled with. But if you want to see the version of libraries, why not make it clearer, e.g.: GNU Wget x.x.x (compiled with OpenSSL x.x.x) BTW can't you find out OpenSSL version by using `ldd'?
Re: small doc update patch
Am Di, 2003-09-16 um 01.09 schrieb Hrvoje Niksic:
Hello,
> >> > --- wget-1.8.2.orig/doc/wget.texi
> >> > +++ wget-1.8.2/doc/wget.texi
> >> > @@ -507,7 +507,7 @@
> >> > @item -t @var{number}
> >> > @itemx [EMAIL PROTECTED]
> >> > Set number of retries to @var{number}. Specify 0 or @samp{inf} for
> >> > -infinite retrying.
> >> > +infinite retrying. Default (no command-line switch) is not to
> >> > retry.
> >>
> >> Huh? The default is to retry 20 times. Isn't it? :-)
> >
> > Hmm, then i got it wrong:
> >
> > $ LC_ALL=C wget -t 0 http://localhost/asdf
> > --00:22:01-- http://localhost/asdf
> >=> `asdf'
> > Resolving localhost... done.
> > Connecting to localhost[127.0.0.1]:80... failed: Connection refused.
>
> It doesn't for "fatal" errors, such as connection refused, and --tries
> doesn't change that.
Hmm, then this should be documented.:)
what about:
--- wget-1.8.2.orig/doc/wget.texi
+++ wget-1.8.2/doc/wget.texi
@@ -507,7 +507,7 @@
@item -t @var{number}
@itemx [EMAIL PROTECTED]
Set number of retries to @var{number}. Specify 0 or @samp{inf} for
-infinite retrying.
+infinite retrying. Default (no command-line switch) is to retry
+20 times but fatal errors like "connection refused" or "not found"
+(404) are not being retried.
Just an idea.
--
Noèl Köthe
Debian GNU/Linux, www.debian.org
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Processing CSS files
(I am not subscribed to this list, please sent a copy of reply to me) When using "-r" or "-p", wget should process CSS files for other files to download. It is very easy to parse a CSS file. See: http://www.w3.org/TR/REC-CSS2/syndata.html#uri > http://www.w3.org/TR/REC-CSS2/cascade.html#at-import > Thanks.
Re: small doc update patch
Noèl Köthe <[EMAIL PROTECTED]> writes:
> -infinite retrying.
> +infinite retrying. Default (no command-line switch) is to retry
> +20 times but fatal errors like "connection refused" or "not found"
> +(404) are not being retried.
Thanks. I've now committed this:
Index: doc/wget.texi
===
RCS file: /pack/anoncvs/wget/doc/wget.texi,v
retrieving revision 1.75
retrieving revision 1.77
diff -u -r1.75 -r1.77
--- doc/wget.texi 2003/09/17 01:32:02 1.75
+++ doc/wget.texi 2003/09/17 21:00:03 1.77
@@ -512,7 +512,9 @@
@item -t @var{number}
@itemx [EMAIL PROTECTED]
Set number of retries to @var{number}. Specify 0 or @samp{inf} for
-infinite retrying.
+infinite retrying. The default is to retry 20 times, with the exception
+of fatal errors like ``connection refused'' or ``not found'' (404),
+which are not retried.
@item -O @var{file}
@itemx [EMAIL PROTECTED]
minor problem with @xref in documentation
Hello,
at the end of the description of the option "--http-passwd=password":
"For more information about security issues with Wget,"
The sentence is incomplete.
wget.texi shows:
"For more information about security issues with Wget, @xref{Security
Considerations}."
The info page has a correct link.
Any idea how to fix this for the manpage?
thx.
--
Noèl Köthe
Debian GNU/Linux, www.debian.org
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: windows compile error
Herold Heiko <[EMAIL PROTECTED]> writes: > Repeatable, and it seems to appear with this: > > 2003-09-15 Hrvoje Niksic <[EMAIL PROTECTED]> > > * retr.c (get_contents): Reduce the buffer size to the amount of > data that may pass through for one second. This prevents long > sleeps when limiting bandwidth. > > * connect.c (connect_to_one): Reduce the socket's RCVBUF when > bandwidth limitation to small values is requested. > > Previous checkout (checkout -D "23:30 15 sep 2003") wget works fine. > I also found a public site which seems to expose the problem (at least from > my machine): > wget -dv https://www.shavlik.com/pHome.aspx > dies after > DEBUG output created by Wget 1.9-beta on Windows. [...] Herold, I'm currently having problems obtaining a working SSL build, so I'll need your help with this. Notice that the above change in fact consists of two changes: one to `retr.c', and the other to `connect.c'. Please try to figure out which one is responsible for the crash. Then we'll have a better idea of what to look for.
Re: Handling of Content-Length 0
Stefan Eissing <[EMAIL PROTECTED]> writes: > Please excuse if this bug has already been reported: > > In wget 1.8.1 (OS X) and 1.8.2 (cygwin) the handling of resources > with content-length 0 is wrong. wget tries to read the empty content > and hangs until the socket read timeout fires. (I set the timeout to > different values and it exactly matches the termination of the GET). > > Of course this is only noticable with HTTP/1.1 server which leave the > connection open and do not apply transfer-encding: chunked for empty > response bodies. I've now examined the source code, and I believe Wget handles this case correctly: if keep-alive is in use, it reads only as much data as specified by Content-Length, attempting no read if content-length is 0. The one case I can see might go wrong is that a server leaves a connection hanging without having told Wget it was about to do so. Then Wget will, being a HTTP/1.0 client, try to read all data from the socket regardless of Content-Length. Do you have a URL which you use to repeat this?
