RE: cURL fails to POST to NTLM protected IIS6 server using ANY authentication with post < 1024bytes

Re: Allocated curl_easy_setopt() strings

On Mon, 30 Jul 2007, Dan Fandrich wrote:

> My only objection is that it forces all option strings to be treated
> strangely and differently compared to other option data

I agree that it changes things around, not necessarily in a good way.

But then I also think that since these strings are now duplicated, it makes a 
little sense to "collect" them logically.

So I still think this approach is the better way even with its drawbacks, when 
we start allocating the strings.

> Putting the strings into a union something like:
>
> union {
>  struct str {
>    char *device;
>    char *set_referer;
>    char *useragent;
>    ...
>  } str;
>  char *allstrings[sizeof(struct str)/sizeof(char *)];
> } strs;
>
> solves this half way, allowing access with data->set.strs.str.device while 
> still allowing access through an array, so even if it's portable it's still 
> a bit ugly.

My recollection of the ANSI C documentation (although admittedly it was some 
years ago since I read them), is that the above approach is _not_ portable 
(although still working on most platforms).

Not that it matters greatly since that is quite hideous looking as well. Also, 
using unorthodox ideas in code is not a good idea when lots of people are 
supposed to be reading and understanding the code, both today and in the 
future.

> I suppose the string array will have to do.  Here are a few minor things I 
> spotted in that patch.

Great! I'll adapt.

--

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html

Re: Endless waiting on POST with zero content length

On Tue, 31 Jul 2007, Emil Romanus wrote:

> That is what I tïred, setting it to NULL to perform an empty POST request. 
> However, as I described libcurl hangs. I added a little test program below, 
> however I am not sure how you want me to attach it, so I'll just copy it 
> into this email. It's pretty short anyway.

Thanks a lot, I'll look into this within a day or two.

--

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html

RE: cURL fails to POST to NTLM protected IIS6 server using ANY authentication with post < 1024bytes

On Tue, 31 Jul 2007, Greg Morse wrote:

> No problem as far as test server and source go.  In fact I am glad to help 
> improve libcurl and I figured someone maintaining this would rather have it 
> straight and to the point.  I tried to anticipate as much as I could to make 
> your job easier.  I am going to take down the test server tomorrow unless 
> you still need it.

I think I'm good for this time. Thanks.

> Can you inform me what build and with which fixes this bug will be fixed in?

I just now committed the patch as I showed it here (although with fixed and 
added comments), so it is in CVS now and will be included in tomorrow's daily 
snapshot and in the upcoming release. (Probably known as version 7.17.0).

--

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html

multi-interface

Re: multi-interface

Hi Peter,

On Wed, Aug 01, 2007 at 03:07:54PM +0100, Peter Thiess wrote:
> I'm a newbie in curl and I read about the multi interface; can anybody 
> clarify if this is a stacking mechanism or if this parallelizes file 
> transfer (e.g. multi-channel FTP) internally.  I am thinking of ways to 
> speed up FTP.

Not sure what you mean by "stacking" - the multi interface indeed 
parallelizes many transfers. This way, your application only needs to have 
one thread even though several downloads are active. Downloads happen in 
the same way as with the simple API, you can just have many at the same 
time.

If you want to use several connections to download chunks of the same file 
in parallel (which BTW is naughty, as it wastes server resources! It even 
violates a HTTP "SHOULD" clause [*]), then you will need to write code 
yourself to reassemble the chunks.

Cheers,

  Richard

[*] RFC 2616, 8.1.4: "A single-user client SHOULD NOT maintain more than 2 
connections with any server or proxy."
--

-- 
  __   _
  |_) /|  Richard Atterer     |  GnuPG key: 888354F7
  | \/¯|  http://atterer.net  |  08A9 7B7D 3D13 3EF2 3D25  D157 79E6 F6DC 8883 54F7
  ¯ '` ¯

Re: multi-interface

RE: multi-interface

Hi Richard,

Thank you very much, this is exactly the information needed; I think of transferring multiple files at the
same time. By stacking I meant a mechanism which works like a serial queue.
Do I understand it correctly that libcurl is opening multiple channels and transfers files at the same
time? If so how many is it scalable? Do you know if examples are available?

Thanks again for your support!

-- peter  

>> -----Original Message-----
>> From: curl-library-bounces <at> cool.haxx.se [mailto:curl-library-
>> bounces <at> cool.haxx.se] On Behalf Of Richard Atterer
>> Sent: Mittwoch, 1. August 2007 16:48
>> To: curl-library <at> cool.haxx.se
>> Subject: Re: multi-interface
>> 
>> Hi Peter,
>> 
>> On Wed, Aug 01, 2007 at 03:07:54PM +0100, Peter Thiess wrote:
>> > I'm a newbie in curl and I read about the multi interface; can anybody
>> > clarify if this is a stacking mechanism or if this parallelizes file
>> > transfer (e.g. multi-channel FTP) internally.  I am thinking of ways to
>> > speed up FTP.
>> 
>> Not sure what you mean by "stacking" - the multi interface indeed
>> parallelizes many transfers. This way, your application only needs to
>> have
>> one thread even though several downloads are active. Downloads happen in
>> the same way as with the simple API, you can just have many at the same
>> time.
>> 
>> If you want to use several connections to download chunks of the same
>> file
>> in parallel (which BTW is naughty, as it wastes server resources! It even
>> violates a HTTP "SHOULD" clause [*]), then you will need to write code
>> yourself to reassemble the chunks.
>> 
>> Cheers,
>> 
>>   Richard
>> 
>> [*] RFC 2616, 8.1.4: "A single-user client SHOULD NOT maintain more than
>> 2
>> connections with any server or proxy."
>> --
>>   __   _
>>   |_) /|  Richard Atterer     |  GnuPG key: 888354F7
>>   | \/¯|  http://atterer.net  |  08A9 7B7D 3D13 3EF2 3D25  D157 79E6 F6DC
>> 8883 54F7
>>   ¯ '` ¯

Re: multi-interface

On Wed, Aug 01, 2007 at 05:23:44PM +0100, Peter Thiess wrote:
> By stacking I meant a mechanism which works like a serial queue.

With the multi interface, there is no such queue.

> Do I understand it correctly that libcurl is opening multiple channels 
> and transfers files at the same time?

Yes - and IIRC there are no limits with regard to the number of 
simultaneous requests (someone correct me if I'm wrong). I think that if 
your application starts lots and lots of requests, it's your own 
responsibility to ensure that it stops doing so once a certain maximum is 
reached.

> If so how many is it scalable? Do you know if examples are available?

Search the list archives - there has been some work on scaling it up to 
several thousand simultaneous connections, I'm not sure how far it has 
proceeded. A couple hundred connections should be no problem!

Cheers,

  Richard

--

-- 
  __   _
  |_) /|  Richard Atterer     |  GnuPG key: 888354F7
  | \/¯|  http://atterer.net  |  08A9 7B7D 3D13 3EF2 3D25  D157 79E6 F6DC 8883 54F7
  ¯ '` ¯

Re: multi-interface