Re: curl -d option and no data is send

On Mon, 31 Mar 2008, Karin Mustermann wrote:

> I´m trying to send data via post method to a webserver in my intranet from 
> the commandline with following options:
>
> curl --data "pin=CP5&value=0&set=Submit" --digest -v --user admin:pass 
> xx.yy.zz

> < HTTP/1.1 400 Bad Request: Invalid Content Length

Interesting. Your server seem to verify the request before it verifies the 
authentication. curl sends a zero length POST when it knows it won't be 
accepted and thus it won't have to send any data in vein.

You can probably work around this problem by using --anyauth instead of 
--digest.

> I tried the -F option too, the output is the same.

-F is not interchangable with -d at your will anyway.

> It seems that curl does not include the data, my Content-Length is always 0.

Indeed, since Digest is a challenge-response based concept curl knows it won't 
send anything in that first POST so it has no intention of sending any data at 
that point.

--

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

Reg : curl_easy_perform() taking 150ms

Re: Reg : curl_easy_perform() taking 150ms

On Wed, 2 Apr 2008, Deepesh Damodaran wrote:

> Once of our application use CURL as FTP mechanism for file transfers between 
> systems. Recently we got a request to increase the throughput of the file 
> transfers. While investigating possible measures to increase the throughput 
> by introducing the logs, we observed curl_easy_perform() routine takes 150ms 
> for connection setup.

> Is there any way to work around this through alternate command line options?

If you want to improve that you should first break that number down even more 
into exactly what stages that take what time. Then see if you can optimize 
that more. curl of course does as good as possible already given the 
requirements and there's no secret --work-faster option.

> I observed latest version of CURL is 7.18.0. Is there any changes in newer 
> version addressing similar problems.

No, the latest is 7.18.1 now.

And this is not a known problem at all.

--

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

Curl and heimdal

First of all (a bit off-toptic), while I do see the spam problem, having
to subscribe to post still sucks.

Now, onto the problem.
While heimdal was detected correctly in curl 7.17.1, when you changed
the order in configure.ac for 7.18.1, it's now identified as MIT.
The reason is that while heimdal has <gssapi.h> in $(prefix)/include ,
unless distributions move it, $(prefix)/include/gssapi/gssapi.h is
present too (check lib/gssapi/Makefile.am of heimdal). Of course,
this means compilation eventually ends with an error.

Re: Curl and heimdal

On Wed, 2 Apr 2008, Rafa Muyo wrote:

(CC'ed to the libcurl list)

> First of all (a bit off-toptic), while I do see the spam problem, having to 
> subscribe to post still sucks.

I agree, but I see no other solution.

> While heimdal was detected correctly in curl 7.17.1, when you changed the 
> order in configure.ac for 7.18.1, it's now identified as MIT. The reason is 
> that while heimdal has <gssapi.h> in $(prefix)/include , unless 
> distributions move it, $(prefix)/include/gssapi/gssapi.h is present too 
> (check lib/gssapi/Makefile.am of heimdal). Of course, this means compilation 
> eventually ends with an error.

Ouch.

So it works fine if you revert this patch? 
http://cool.haxx.se/cvs.cgi/curl/configure.ac.diff?r1=1.276&r2=1.277

--

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

Re: Curl and heimdal

Daniel Stenberg wrote:
> On Wed, 2 Apr 2008, Rafa Muyo wrote:
>> While heimdal was detected correctly in curl 7.17.1, when you changed the 
>> order in configure.ac for 7.18.1, it's now identified as MIT. The reason is 
>> that while heimdal has <gssapi.h> in $(prefix)/include , unless 
>> distributions move it, $(prefix)/include/gssapi/gssapi.h is present too 
>> (check lib/gssapi/Makefile.am of heimdal). Of course, this means compilation 
>> eventually ends with an error.

So both mit and heimdal have both /usr/include/gssapi.h and
/usr/include/gssapi/gssapi.h? Great :-/

> So it works fine if you revert this patch? 
> http://cool.haxx.se/cvs.cgi/curl/configure.ac.diff?r1=1.276&r2=1.277

I'll have a look if it's possible to distinguish the two versions more
reliably.

Michal

Re: Curl and heimdal

Well, I haven't checked it, but it should, as this is exactly the change
I was talking about.

BTW. CC me, cause though I'm subscribed, I turned off mail delivery.
And on a semi-related note, why did your mail program tried to mutilate
my post ? I can understand what web mail archive did (is sets
page encoding to latin 1, while mail header was mime-encoded utf8), but
your program simply swallowed those few letters.

Re: Curl and heimdal

Michal Marek wrote:
> Daniel Stenberg wrote:
>> On Wed, 2 Apr 2008, Rafa Muyo wrote:
>>> While heimdal was detected correctly in curl 7.17.1, when you changed the 
>>> order in configure.ac for 7.18.1, it's now identified as MIT. The reason is 
>>> that while heimdal has <gssapi.h> in $(prefix)/include , unless 
>>> distributions move it, $(prefix)/include/gssapi/gssapi.h is present too 
>>> (check lib/gssapi/Makefile.am of heimdal). Of course, this means compilation 
>>> eventually ends with an error.
> 
> So both mit and heimdal have both /usr/include/gssapi.h and
> /usr/include/gssapi/gssapi.h? Great :-/
> 
>> So it works fine if you revert this patch? 
>> http://cool.haxx.se/cvs.cgi/curl/configure.ac.diff?r1=1.276&r2=1.277
> 
> I'll have a look if it's possible to distinguish the two versions more
> reliably.

I hope to have something by today, I think something like this should work:

if gssapi/gssapi.h, gssapi/gssapi_generic.h and gssapi/gssapi_krb5.h are
all available
  HAVE_GSSMIT
  if GSS_C_NT_HOSTBASED_SERVICE is not declared
    then it's an old mit kerberos, define it to gss_nt_service_name
  fi
else if gssapi.h is available
  HAVE_GSSHEIMDAL
fi

Michal

Re: Curl and heimdal

Michal Marek wrote:
> Daniel Stenberg wrote:
>> On Wed, 2 Apr 2008, Rafa Muyo wrote:
>>> While heimdal was detected correctly in curl 7.17.1, when you changed the 
>>> order in configure.ac for 7.18.1, it's now identified as MIT. The reason is 
>>> that while heimdal has <gssapi.h> in $(prefix)/include , unless 
>>> distributions move it, $(prefix)/include/gssapi/gssapi.h is present too 
>>> (check lib/gssapi/Makefile.am of heimdal). Of course, this means compilation 
>>> eventually ends with an error.
> 
> So both mit and heimdal have both /usr/include/gssapi.h and
> /usr/include/gssapi/gssapi.h? Great :-/
> 
>> So it works fine if you revert this patch? 
>> http://cool.haxx.se/cvs.cgi/curl/configure.ac.diff?r1=1.276&r2=1.277
> 
> I'll have a look if it's possible to distinguish the two versions more
> reliably.

Please try the attached patch. Apply it to unmodified source, run
./buildconf and then ./configure as usual. Please tell me if it works
for you or not and post the output of

  grep GSS lib/config.h

after running ./configure.

Please CC me, as I don't receive mail from curl-users.

thanks,
Michal

RE: Curl and ssl