Andre Pang <[EMAIL PROTECTED]> writes:
>> >> --range=1025..2048
>> >> --range=1024..2047
>> >
>> > I haven't been following that closely, but how are you going to
>> > tell what the user really wants to do if he gives either of those
>> > two statements?
>>
>> Only one of those statements will
On Mon, Nov 19, 2001 at 08:33:15PM +0100, Hrvoje Niksic wrote:
> Compatibility with rfc2616 is a good point, though. Maybe it's best
> to simply stick to 1024-2047 then.
Compatibility with curl is even more important :). In light of
that, I vote for 1024-2047. No point having two file retriev
On Mon, Nov 19, 2001 at 08:19:08PM +0100, Hrvoje Niksic wrote:
> >> --range=1025..2048
> >> --range=1024..2047
> >
> > I haven't been following that closely, but how are you going to
> > tell what the user really wants to do if he gives either of those
> > two statements?
>
> Only one of those
Daniel Stenberg <[EMAIL PROTECTED]> writes:
> Then again, both versions could be supported if they just use
> different syntaxes.
Please note that there is a third version which Andre elided. We're
deciding for one or more of:
--range=1025..2048
--range=1024..2047
--range=1024..2048 # m
Hi,
I found this address in the Emacs info pages for wget.
I have wget version 1.5.3 and try to run the command
wget -r -X cgi-bin http://susning.nu/
but it does retrieve a lot of stuff in the /cgi-bin/ directory.
Is this a bug, or is there any reasonable explanation?
In fact, it would be
On Mon, 19 Nov 2001, Hrvoje Niksic wrote:
> >> --range=1025..2048
> >> --range=1024..2047
>
> Only one of those statements will be a valid way of downloading the
> second kilobyte of a file. The question is, which one.
>
> The first one assumes the first byte in the file is "1", the second one
>
Andre Pang <[EMAIL PROTECTED]> writes:
> On Mon, Nov 19, 2001 at 05:07:31PM +0100, Hrvoje Niksic wrote:
>
>> Or, to pick another example, say you want to download the second
>> kilobyte of a file:
>>
>> --range=1025..2048
>> --range=1024..2047
>
> I haven't been following that closely, but how
On Mon, Nov 19, 2001 at 05:07:31PM +0100, Hrvoje Niksic wrote:
> Or, to pick another example, say you want to download the second
> kilobyte of a file:
>
> --range=1025..2048
> --range=1024..2047
I haven't been following that closely, but how are you going to
tell what the user really wants to
The retry mechanism might be okay for http, but many ftp sites consider
retries within 60 seconds as hammering.
If backward compatibility is the goal, it would seem that this could be
achieved by setting the default waitretry to 0, and leave it there if
there is no other specification. wget-1.5.
Herold Heiko <[EMAIL PROTECTED]> writes:
> However, of the top of my head I can't remember many occasions where
> 0-n means closed-open
There are. (And note that it's n-m in the general case, not just
0-n.) Off the top of my head, the Java string subscripts, Lisp
array-related functions, Pytho
On Mon, 19 Nov 2001, Karr, David wrote:
> I've noticed a tool recently called "cURL" that seems to be in the same
> "space" as "wget". Could someone give me a basic overview of how these
> two things are different?
Basically, I'd say that wget gets things recursively, and curl doesn't.
A somew
I've noticed a tool recently called "cURL" that seems to be in the same
"space" as "wget". Could someone give me a basic overview of how these two
things are different?
Herold Heiko <[EMAIL PROTECTED]> writes:
> Personally I'd be happy either way, but you'll never be able to make
> happy everybody. Choose what you prefer
I'd love to choose what I prefer, but I'd like to avoid my wild
preferences ruining it for everyone else. :-) Thanks for the
support, though
>From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]]
>
>[ Note for Wget list readers: this discusses the `--range' option
> submitted to the patch list. ]
>
>Herold Heiko <[EMAIL PROTECTED]> writes:
>
>> Also, possibly I missed something, does the download start at byte 0
>But you've still rais
[ Note for Wget list readers: this discusses the `--range' option
submitted to the patch list. ]
Herold Heiko <[EMAIL PROTECTED]> writes:
> Also, possibly I missed something, does the download start at byte 0
> (like most programmers ecc. would expect) or at byte 1 (like most users
> would exp
>Herold Heiko <[EMAIL PROTECTED]> writes:
>
>> At the moment I wrote (rather badly) the waitretry patch I thought
>> at backwards compatibility for existing installations - that is,
>> somebody with new wget, but existing .wgetrc (no waitretry set) and
>> existing scripts (no --waitretry set) shou
Bernhard Simon <[EMAIL PROTECTED]> writes:
>> Thanks for the patch; I believe this problem was fixed in 1.7.1,
>> released several hours ago. Could you please check if that version
>> works out of the box?
>
> Yes, it works out of the box now. Thanks!
Always nice to hear. Thanks for testing i
Herold Heiko <[EMAIL PROTECTED]> writes:
> The latest changes require the attached patch to windows/* for the
> md5 and res files (borland/watcom stuff not tested).
Thanks for the update. I've applied your patch to CVS.
Note: it's always a good idea to Cc a patch to the patches list.
The latest changes require the attached patch to windows/* for the md5
and res files (borland/watcom stuff not tested).
A couple of new binaries (1.7.1 and the current 1.8) are up at
http://space.tin.it/computer/hherold for your testing pleasures, alas as
usual without ssl support due to the copy
Herold Heiko <[EMAIL PROTECTED]> writes:
> At the moment I wrote (rather badly) the waitretry patch I thought
> at backwards compatibility for existing installations - that is,
> somebody with new wget, but existing .wgetrc (no waitretry set) and
> existing scripts (no --waitretry set) should ham
Nice bug :(
Well, currently the sample .wgetrc tries to be "nice" to remote servers
- that is, avoid hammering, and as such has waitretry set to something
>0 (increasing delays if the connection is lost). At the same moment the
goal is to have a nice and fast download - default wait = 0.
At the
Same here unfortunately. I haven't been able to reproduce it anymore
after I vastly cleaned up my cookies - so I fear there could be
something lurking in the cookie handling (possibly regarding the number
of cookies, or the size of some content ? ). Or possibly it was just a
problem with my build,
22 matches
Mail list logo
