Re: mem leak in http.c
T. Bharath [EMAIL PROTECTED] writes: There seems to be mem leak happening when a persistant ssl connection is enabled. The leak actually happens in gethttp() and its related set of functions that register and check for persistant connectionsWhen a server promises a persistant connection we register it but later say the connection times out we close the socket descriptor but we donot delete the SSL struct causing the leak Below is a patch that fixes that Thanks for the patch; I've now applied it to the CVS.
Re: compile problem on HP-UX, with patch! :)
Torgeir Hansen [EMAIL PROTECTED] writes: Error compiling wget-1.7.1 on HP-UX10.20 with gcc version 3.0.1: --- snprintf.c:343: `short unsigned int' is promoted to `int' when passed through `...' snprintf.c:343: (so you should pass `int' not `short unsigned int' to `va_arg') snprintf.c:357: `short unsigned int' is promoted to `int' when passed through `...' *** Error exit code 1 Can someone comment on this? First, I find it strange that HPUX doesn't have snprintf. Second, why doesn't va_arg just do the necessary promotion?
Re: wget1.7.1: Compilation Error (please Cc'ed to me :-)
Ian Abbott [EMAIL PROTECTED] writes: A memmove() replacement has already been added to Wget in CVS, but here is a patch to use bcopy() if available. I was thinking about this for some time. The reasons I chose to roll in the memmove() from GNU libit rather than use bcopy are the following: * It seems that bcopy handles overlapping blocks on *some* architectures. But searching the net showed that many people believe it not to be safe to rely on this for *all* architectures. * Perl actually uses configure to check whether bcopy() handles overlaps. Another vote for the statement that bcopy() can be overlap-unsafe. (But I would like to avoid doing that check in Wget because of cross-compiled builds and because I'm not sure there's a way to *prove* that bcopy works with overlapping blocks in a general way.) * If we ever do encounter an architecture with overlap-unsafe bcopy, the bug will be very hard to detect because it will have been buried in a little-used area in Wget. Still, it will be there and it might cause occasional and weird bugs. * Wget can live with a less-than-fully optimized memmove. The reason I wanted to use bcopy is not so much of speed, but simply because I *like* to reuse the existing library functionality. But if such reuse carries a potential unsafety, it's just not worth it.
Re: v. 1.7: problem converting to relative links with -k
[ Sorry for answering so late; I'm going through a back log. ] Mark Holt [EMAIL PROTECTED] writes: I am writing a site copier program for a free web hosting company. In testing the -k option, I find that it only converts absolute links to relative links if it has already downloaded the page in question through a relative link. BUT if there is only one link to a certain page, and that link is absolute, the link won't be converted and the document won't get downloaded. Is this accurate? Two things here: * What does and what doesn't get downloaded is a function of the parameters you specify. You can tell Wget to only download relative links, and it will happily do so. But if you don't tell it that, and it still refuses to download absolute links, it's a bug. * What gets converted is a function of what was downloaded. A link that was downloaded will be converted to a relative link referring to the relative position of the downloaded file. A link that was not downloaded will be converted to an absolute link (http://...). If this doesn't happen, it's a bug. Having said that, please also note that sometimes strange URLs, redirections, etc., can confuse Wget. The recursive retrieval and URL handling logic has been vastly improved for Wget 1.8 (currently available through CVS), and many of these bugs have been fixed. If you have time and still have this problem, please download the latest CVS sources and see if the problem persists. http://wget.sunsite.dk explains how to download the sources from CVS.
Hi, Friend! We wish You a pleasant and successful day!
DEAR FRIEND! If You show some interest and patience, and visit http://www.escalix.com/freepage/goldflow/, You can earn up to $100,000 and more during the following 120 days - it depends only on You. DOES IT SEEMS TO BE IMPOSSIBLE??? Just visit link below and read attentively to be sure there is no catch or deceit. If You are completely lazy - we beg Your pardon for the assumption!!! Then this is not for You!!! You'd better do something like surfing either clicking on banners or not doing anything at all. If the offer hasn't interested You, we bring our apologies and it is not necessary to get angry - spam has its expenses, just as radio and TV, but do not forget, that the first billionaire of the USA, Dale Carnegie said: I'll better earn 1% as a result of the efforts of 100 men, than 100% as a result of my own efforts. RISE ON THE WAY TO THE FINANCIAL INDEPENDENCE AND FREEDOM!!!
why didnt you come watch me on my webcam? you said you would! w
Below is the result of your feedback form. It was submitted by ([EMAIL PROTECTED]) on Friday, November 30, 2001 at 22:14:55 --- : hey babe, it's karina remember me? if you don't im 5'8 with brown hair and blue :eyes with an ass you can bounce a quarter off of :) Im 21 years old and im in my :final year of college at OSU in OREGON! i just got my first webcam and i love meeting :new people on it and just showing my body off. i want you to come watch me do a :striptease! my website is located at: http://sepimpin.brinkster.net/ if that doesnt :work try http://karina.tk.ru/ ~ LOVE ALWAYS! -Karina XOXOXO33 ---
Wget 1.8-beta1 now available
Here is a beta version of what is to be 1.8. In this case, beta does not mean instability, just that I'd like a wider audience to take a look at the thing before we can call it a prerelease. In either case, I'm aiming for a release soon, possibly within the week. Get it from: ftp://gnjilux.srk.fer.hr/pub/unix/util/wget/.betas/wget-1.8-beta1.tar.gz (The `.betas' directory is intentionally unreadable, but the file is there.)
Re: wget mirroring busted
Jamie Zawinski [EMAIL PROTECTED] writes: [...] It's downloading about every 4th subdirectory under gallery/2001/; if you look at the index.html file there, you'll see that all links are in identical syntax, so I don't see why it's downloading 07-13/ but skipping 07-14/. And then, strangely, if I leave off the flyers/ URL on the command line, it downloads more of the gallery/ directories -- but not all of them. I'm not sure what exactly is going on here, but I would guess that Wget 1.7 tried to be overzealous about remembering which URLs are undesirable to load, and thus had one recursive download hose the other. Or something like that. I've rewritten the recursive download code for 1.8 to traverse the links breadth-first, and to be much less zealous about blacklisting the URLs chosen not to be downloaded at some random point. I believe the bug you saw has been fixed. I've now tried your test case and I got this: $ find flyers gallery -type d | sort flyers flyers/2001 flyers/2001/07 flyers/2001/08 flyers/2001/09 flyers/2001/10 flyers/2001/11 flyers/2001/12 gallery gallery/2001 gallery/2001/07-13 gallery/2001/07-14 gallery/2001/07-28 gallery/2001/08-01 gallery/2001/08-04 gallery/2001/08-10 gallery/2001/08-17 gallery/2001/08-31 gallery/2001/09-01 gallery/2001/09-16 gallery/2001/09-20 gallery/2001/09-23 gallery/2001/10-05 gallery/2001/10-14 gallery/2001/10-31 gallery/2001/11-15 It downloads 978 JPG and 9 GIF files in total. Wget 1.8 is officially in beta, but it's quite stable. If you want to try if it works for you, grab it from here: ftp://gnjilux.srk.fer.hr/pub/unix/util/wget/.betas/wget-1.8-beta1.tar.gz Thanks for the report.
Re: wget chokes on http redirects to # anchors
Jamie Zawinski [EMAIL PROTECTED] writes:
The log says it all; it's treating the # as part of the URL
instead of stripping it.
Thanks for the report; I believe this bug has been fixed in 1.8:
{florida}[~/work/wget/src]$ ./wget http://www.dnalounge.com/backstage/log/latest.html
--04:41:48-- http://www.dnalounge.com/backstage/log/latest.html
= `latest.html'
Resolving www.dnalounge.com... done.
Connecting to www.dnalounge.com[209.157.129.108]:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.dnalounge.com/backstage/log/2001/11.html#18-nov-2001 [following]
--04:41:48-- http://www.dnalounge.com/backstage/log/2001/11.html
= `11.html'
Connecting to www.dnalounge.com[209.157.129.108]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15,981 [text/html]
100%[===]15,981 36.04K/s ETA 00:00
04:41:49 (36.04 KB/s) - `11.html' saved [15981/15981]
My previous message contains the URL you can get Wget 1.8 from.
Re: WGET: core dump in 1.7 and latest CVS?
L. Cranswick [EMAIL PROTECTED] writes: With the latest CVS version of wget (and the 1.7 distribution) is there a known reason and fix why wget core dumps on the following site? Could you please check whether the core dump persists with the latest CVS version, or with the recently announced 1.8-beta1? Quite a lot of code has been changed, and it is entirely possible that this problem has gone away. Thanks for the report.
