Re: wget 1.10 alpha 1
From: Mauro Tortonesi [EMAIL PROTECTED] [...] i think that if you want your patches to be merged in our CVS, you should follow the official patch submission procedure (that is, posting your patches to the wget-patches AT sunsite DOT dk mailing list. each post should include a brief comment about what the patch does, and especially why it does so). this would save a lot of time to me and hrvoje and would definitely speed up the merging process. [...] Perhaps. I'll give it a try. Also, am I missing something obvious, or should the configure script (as in, To configure Wget, run the configure script provided with the distribution.) be somewhere in the CVS source? I see many of its relatives, but not the script itself. And I'm just getting started, but is there any good reason for the extern variables output_stream and output_stream_regular not to be declared in some header file? Steven M. Schweda (+1) 651-699-9818 382 South Warwick Street[EMAIL PROTECTED] Saint Paul MN 55105-2547
Re: wget 1.10 alpha 1
On Tue, 12 Apr 2005, Steven M. Schweda wrote: Also, am I missing something obvious, or should the configure script (as in, To configure Wget, run the configure script provided with the distribution.) be somewhere in the CVS source? I see many of its relatives, but not the script itself. You can use Makefile.cvs (i.e. make -f Makefile.cvs), which will run autoheader and autoconf. The autoheader command creates src/config.h.in and the autoconf command creates configure from configure.in. I usually just run autoheader and autoconf directly. You need to have Autoconf and m4 installed. Doug -- Doug Kaufman Internet: [EMAIL PROTECTED]
Re: wget 1.10 alpha 1
[EMAIL PROTECTED] (Steven M. Schweda) writes: Also, am I missing something obvious, or should the configure script (as in, To configure Wget, run the configure script provided with the distribution.) be somewhere in the CVS source? The configure script is auto-generated and is therefore not in CVS. To get it, run autoconf. See the file README.cvs. And I'm just getting started, but is there any good reason for the extern variables output_stream and output_stream_regular not to be declared in some header file? No good reason that I can think of.
How can wget work with http proxy which support CONNECT method?
I have a http proxy, it's address is http://10.0.0.172 80 I think it is a HTTP/1.1 proxy, beacuse I can support CONNECT method. My problem is GET ftp://ftp.gnu.org/pub/gnu/wget/wget-1.9.tar.gz HTTP/1.0 ^ doesn't work, but CONNECT ftp.gnu.org:21 HTTP/1.0 does work(I have tested by a ftp client which support HTTP/1.1 proxy). How can I turn wget send CONNECT request to HTTP proxy after connected, instead of send GET request? HERE IS MY DEBUG OUTPUT: C:\Documents and Settings\zkecho %ftp_proxy% http://10.0.0.172:80 C:\Documents and Settings\zkwget -d ftp://ftp.gnu.org/pub/gnu/wget/wget-1.9.tar .gz DEBUG output created by Wget 1.9+cvs-dev-200404081407 on Windows. --21:58:04-- ftp://ftp.gnu.org/pub/gnu/wget/wget-1.9.tar.gz = `wget-1.9.tar.gz' Connecting to 10.0.0.172:80... seconds 0.00, connected. Created socket 1956. Releasing 003F5078 (new refcount 0). Deleting unused 003F5078. ---request begin--- GET ftp://ftp.gnu.org/pub/gnu/wget/wget-1.9.tar.gz HTTP/1.0 ^ User-Agent: Wget/1.9+cvs-dev-200404081407 Accept: */* Host: ftp.gnu.org Connection: Keep-Alive ---request end--- Proxy request sent, awaiting response... ---response begin--- HTTP/1.0 501 OCCURRED ^^^ Content-Length:0 Connection: Keep-Alive ---response end--- 501 OCCURRED Registered socket 1956 for persistent reuse. 21:58:05 ERROR 501: OCCURRED.
Re: How can wget work with http proxy which support CONNECT method?
gu gu [EMAIL PROTECTED] writes: I have a http proxy, it's address is http://10.0.0.172 80 I think it is a HTTP/1.1 proxy, beacuse I can support CONNECT method. My problem is GET ftp://ftp.gnu.org/pub/gnu/wget/wget-1.9.tar.gz HTTP/1.0 ^ doesn't work, but CONNECT ftp.gnu.org:21 HTTP/1.0 That's strange. I've never seen a proxy that doesn't support the former. Has this use of CONNECT become standard while I wasn't looking? How does it allow you to establish FTP data connections? Cursory googling seems to reveal that using CONNECT for anything other than SSL constitutes abuse of CONNECT. Apache's mod_proxy allows CONNECT only to ports 443 and 563 (https and snews). Mozilla uses the proxy just like Wget does (I tested it by listening on a local port with nc and connecting with Mozilla 1.7.6). None of the above is authoritative evidence, but it is very telling. The CVS Wget supports the CONNECT method, but uses it only for HTTPS requests over HTTP proxies.
wget 1.10 alpha 2
dear friends, i have just released the second alpha version of wget 1.10: ftp://ftp.deepspace6.net/pub/ds6/sources/wget/wget-1.10-alpha2.tar.gz ftp://ftp.deepspace6.net/pub/ds6/sources/wget/wget-1.10-alpha2.tar.bz2 you are encouraged to download the tarballs, test if the code works properly (especially WRT LFS support and NTLM authentication) and report any bug you find. i remind you that the feature freeze for the release of wget 1.10 started last sunday (april 10th) and that the only patches that will be accepted and merged into our cvs until the 1.10 release will be (hopefully minor) bugfixes. in the last days a lot of patches have been submitted to the wget-patches mailing list. most of them are very interesting, but since the new features introduced in wget 1.10 are already very significant and i would like to release the new version of wget before the end of this month, i chose not to merge any of those patches and leave them for wget 1.11. anyway, here is a brief report on the status of those pending patches: garycao's strict quota enforcement patch: Unfortunately garycao's patch is not ready for inclusion yet. Anyway, strict quota enforcing will be absolutely added to wget 1.11. Johannes Hoff's specify SSL cypher patch: IMVHO, this patch adds an interesting feature to wget. i will consider merging it in wget 1.11. Leonid Petrov's --persistent patch: this patch adds a very useful feature and will be merged in cvs as soon as the development cycle for wget 1.11 starts. Jim Wright's --waitretry patch: this patch changes the semantics of the --waitretry switch. Jim also proposes to keep the current semantics by introducing a new --waitretrylimit switch. although i like Jim's approach, his patch is just a simple hack which needs some work to be integrated and before changing the semantics of a command switch i would like to investigate if this could cause any significant problem for the users. Jim Wright's no partial files patch: i think deletion of partially retrieved files is another useful feature which deserves to be added to wget ASAP. however, at this stage Jim's patch is just a hack that works only for FTP (it would be nice to support HTTP as well) and definitely needs a lot of work before being integrated. Doug Kaufman's DOS patch: this patch needs a bit of cleaning. i am not planning to merge this patch into wget anytime soon, as its code is very intrusive and even harder to maintain since neither i or hrvoje have access to a DOS system with watt32. however, if doug agrees and keeps maintaining its patch, for the moment we can distribute the DOS support code as a separate patch, which would be downloadable from the official wget FTP repository. Steven Schweda's VMS patches: unfortunately i haven't seen these patches yet, but the same considerations i have written above about DOS support apply also to the VMS support. Tobias Tiederle's regex patch: regex is a very nice feature which i am planning to include in a future release of wget (hopefully 1.11). but, since wget supports so many platforms, we have to come up with a portable implementation of regex and i don't know yet if from this point of view using the PCRE library as Tobias does in its patch is the best thing to do. i would like to hear other opinions on this point. i hope i haven't forgot any other patches. if so, please tell me. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi University of Ferrara - Dept. of Eng.http://www.ing.unife.it Institute of Human Machine Cognition http://www.ihmc.us Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Wget error
Hi! I attempted to download wget onto my mac. I was disappointed to find that it would not work. I thought that I read it was applicable to macs, but am I wrong? Please let me know, Thank you so much. - please respond to [EMAIL PROTECTED]
Re: Wget error
On Tuesday 12 April 2005 06:17 pm, Jeanne McIlvain wrote: Hi! I attempted to download wget onto my mac. I was disappointed to find that it would not work. I thought that I read it was applicable to macs, but am I wrong? Please let me know, Thank you so much. - please respond to [EMAIL PROTECTED] did you download the source tarball and compile it? which version of wget are you using? which version of mac os? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi University of Ferrara - Dept. of Eng.http://www.ing.unife.it Institute of Human Machine Cognition http://www.ihmc.us Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.10 alpha 1
From: Hrvoje Niksic [EMAIL PROTECTED] Also, am I missing something obvious, or should the configure script (as in, To configure Wget, run the configure script provided with the distribution.) be somewhere in the CVS source? The configure script is auto-generated and is therefore not in CVS. To get it, run autoconf. See the file README.cvs. Sorry for the stupid question. I was reading the right document but then I got distracted and failed to get back to it. Thanks for the quick, helpful responses. And I'm just getting started, but is there any good reason for the extern variables output_stream and output_stream_regular not to be declared in some header file? No good reason that I can think of. I'm busy segregating all/most of the VMS-specific stuff into a vms directory, to annoy the normal folks less. Currently, I have output_stream, output_stream_regular, and total_downloaded_bytes in (a new) main.h, but I could do something else if there's a better plan. Rather than do something similar for version_string, I just transformed version.c into version.h, which (for the moment) contains little other than: #define VERSION_STRING 1.10-alpha1_sms1 Was there any reason to do this with a source module instead of a simple macro in a simple header file? Was there any reason to use '#include config.h' instead of '#include config.h'? This hosed my original automatic dependency generation, but a work-around was easy enough. It just seemed like a difference from all the other non-system inclusions with no obvious (to me) reason. Currently, I'm working from a CVS collection taken on 11 April. Assuming I can get this stuff organized in the next few days or so, what would be the most convenient code base to use? Steven M. Schweda (+1) 651-699-9818 382 South Warwick Street[EMAIL PROTECTED] Saint Paul MN 55105-2547
