headers
Brian J. Murrell | 1 Mar 2009 04:38
Picon

Re: how to use --proxy-negotiate, exactly?

On Thu, 26 Feb 2009 13:14:40 +0100, Daniel Stenberg wrote:
> 
> It is a hack and while it may very well work for you it isn't something
> we can proceed with.

Absolutely agreed.  That's why I called it a hack, as it was meant purely 
to demonstrate how a more proper fix could be instrumented.

> Thus, if it was indeed "picked" you check if 'negdata->context' is NULL
> and if it is you init it at that point and then move on.

Yeah, that sounds right.

> Something
> similar to this perhaps:
> 
>    if(authstatus->picked == CURLAUTH_GSSNEGOTIATE) &&
>       !GSS_ERROR(negdata->status)) {
>      int ret=0;
> 
>      auth="GSS-Negotiate";

Any reason you init this with GSS-Negotiate and not just Negotiate?  The 
difference observed here that with GSS-Negotiate the service name is 
KHTTP <at> server and with Negotiate, it's HTTP <at> server.  The latter is correct 
for my usage.

But otherwise, yes this solution corrects the problem, indeed.

I've actually not yet understood the subtle difference between Negotiate
(Continue reading)

Permalink | Reply | 13 comments |
headers
Daniel Stenberg | 1 Mar 2009 12:50
Picon
Favicon
Gravatar

Re: how to use --proxy-negotiate, exactly?

On Sun, 1 Mar 2009, Brian J. Murrell wrote:

>>      auth="GSS-Negotiate";
>
> Any reason you init this with GSS-Negotiate and not just Negotiate?

Because I had to pick one!

> The difference observed here that with GSS-Negotiate the service name is 
> KHTTP <at> server and with Negotiate, it's HTTP <at> server.  The latter is correct 
> for my usage.

Right, so now we know why the code needs a round-trip to know exactly how to 
behave. Possibly it could try both HTTP <at>  and KHTTP <at>  so it would work for both 
cases. But the code is also sprinkled with logic dependent on HAVE_SPNEGO.

Ideally we'd have someone with access/use for all three kinds as then there 
would be the least risk for breakage. But I doubt there's anyone like that 
here right now...

> I've actually not yet understood the subtle difference between Negotiate
> and GSS-Negotiate TBH.

Me neither.

> There does seem to be one, yet there is only a single CURLAUTH_* definition 
> (and a single command line option to request it) covering both of them, even 
> though there does seem to be a subtle difference between how the two 
> operate.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Brian J. Murrell | 1 Mar 2009 15:27
Picon

Re: how to use --proxy-negotiate, exactly?

On Sun, 01 Mar 2009 12:50:19 +0100, Daniel Stenberg wrote:
> 
> Because I had to pick one!

LOL.  OK.  Fair enough.

> Right, so now we know why the code needs a round-trip to know exactly
> how to behave.

I would suggest that if a user could not provide enough information, then 
a round trip is acceptable, but I think the user should be able to 
provide enough information to avoid that.  Having to make two round trips 
for every single request is just sub-optimal.  It increases latency and 
litters the proxy logs with "false denials".

> Possibly it could try both HTTP <at>  and KHTTP <at>  so it would
> work for both cases. But the code is also sprinkled with logic dependent
> on HAVE_SPNEGO.

Yeah, not sure how SPNEGO fits into [GSS-]Negotiate either, TBH.

> Ideally we'd have someone with access/use for all three kinds as then
> there would be the least risk for breakage.

Indeed.

> But I doubt there's anyone
> like that here right now...

Agreed.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Daniel Stenberg | 1 Mar 2009 15:39
Picon
Favicon
Gravatar

Re: how to use --proxy-negotiate, exactly?

On Sun, 1 Mar 2009, Brian J. Murrell wrote:

> I would suggest that if a user could not provide enough information, then a 
> round trip is acceptable, but I think the user should be able to provide 
> enough information to avoid that.  Having to make two round trips for every 
> single request is just sub-optimal.  It increases latency and litters the 
> proxy logs with "false denials".

Indeed. I think this is an issue worth persuing and fixing.

This said, an app that would use more than one request would re-use the 
libcurl handle and thus retain the knowledge about the proxy and then not do 
round-trips for every subsequent request. It's just of course the fact that if 
you use curl it kills the connection all the time so it cannot do this...

> I wonder if we can find 3 people, each with the ability to test one of the 
> three.  I'm happy to be the "Negotiate" guinea-pig.

I think moving this thread to the curl-library list will increase the chances, 
not only that there will be a user like this but that we'll attract interest
from a few other devs.

>> They are covered with a single bit just because we've gotten away with that 
>> so far, and we've seen no reason to introduce two separate ones.
>
> But perhaps we are finding the need now for another bit?  Or do you still 
> think we can, somehow achieve the goal of providing curl with enough 
> information to retrieve a URL with only a single trip to the proxy without 
> adding a new bit?
(Continue reading)

Permalink | Reply | 10 comments |
headers
Honey Dont | 2 Mar 2009 00:09
Picon
Favicon

Parameters in CURLOPT_WRITEFUNCTION:


Hi there. I'm new to cURL and going through examples and the tutorial. In the CURLOPT_WRITEFUNCTION you
have four parameters, two of which is size_t size, and size_t nmemb.  In the doc for this function it is said,
"The size of the data pointed to by ptr is size multiplied with nmemb."  

Is this to account for the difference in ascii and unicode?  In other words nmemb is the number of elements
pointed to by ptr and size is either equal to one or two depending on whether unicode is being used or not?

I think it is, but the question just nags at me for confirmation.

Thanks.

      
-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Permalink | Reply | 3 comments |
headers
Brian J. Murrell | 2 Mar 2009 05:31
Picon

Re: how to use --proxy-negotiate, exactly?

On Sun, 01 Mar 2009 15:39:21 +0100, Daniel Stenberg wrote:
> 
> Indeed. I think this is an issue worth persuing and fixing.

Excellent.

> This said, an app that would use more than one request would re-use the
> libcurl handle and thus retain the knowledge about the proxy and then
> not do round-trips for every subsequent request. It's just of course the
> fact that if you use curl it kills the connection all the time so it
> cannot do this...

Exactly.  The repeated calls to curl was exactly the use case I was 
considering.

> I think moving this thread to the curl-library list will increase the
> chances, not only that there will be a user like this but that we'll
> attract interest from a few other devs.

OK.  If you want to move it, go ahead and I will follow.

> Assuming we can do that check for both HTTP <at>  and KHTTP <at>  we might still
> be able to get away with the single bit.

Indeed.  I had thought about this a few hours ago myself.  Keeping it 
simple, we could change up the:

    auth="GSS-Negotiate";
    if(!negdata->context)
      /* if explicitly selected it isn't inited at this point */
(Continue reading)

Permalink | Reply | 9 comments |
headers
Daniel Stenberg | 2 Mar 2009 09:41
Picon
Favicon
Gravatar

Re: Parameters in CURLOPT_WRITEFUNCTION:

On Sun, 1 Mar 2009, Honey Dont wrote:

You're obviously using the library so I would strongly recommend that you use 
the curl-library mailing list instead!

> Hi there. I'm new to cURL and going through examples and the tutorial. In 
> the CURLOPT_WRITEFUNCTION you have four parameters, two of which is size_t 
> size, and size_t nmemb.  In the doc for this function it is said, "The size 
> of the data pointed to by ptr is size multiplied with nmemb."
>
> Is this to account for the difference in ascii and unicode?

Not at all. It doesn't take anything particular into "account", it just tells 
you the size of the data and it uses the same argument set that fwrite() 
offers which is why it uses two arguments to specify the size.

> In other words nmemb is the number of elements pointed to by ptr and size is 
> either equal to one or two depending on whether unicode is being used or 
> not?

libcurl delivers binary data and it has no idea about what it delivers so it 
cannot make any such distinction.

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Stenberg | 2 Mar 2009 14:02
Picon
Favicon
Gravatar

Re: how to use --proxy-negotiate, exactly?

On Mon, 2 Mar 2009, Brian J. Murrell wrote:

This thread is now taken over to the curl-library list from curl-users. The 
thread so far can be viewed here =>

 	http://curl.haxx.se/mail/archive-2009-02/index.html#90

>> Assuming we can do that check for both HTTP <at>  and KHTTP <at>  we might still
>> be able to get away with the single bit.
>
> Indeed.  I had thought about this a few hours ago myself.  Keeping it
> simple, we could change up the:
>
>    auth="GSS-Negotiate";
>    if(!negdata->context)
>      /* if explicitly selected it isn't inited at this point */
>      ret = Curl_input_negotiate(conn, proxy, auth);
>
> with:
>
>    auth="GSS-Negotiate";
>    if(!negdata->context)
>      /* if explicitly selected it isn't inited at this point */
>      if ((ret = Curl_input_negotiate(conn, proxy, auth)) < 0) {
>        auth="Negotiate";
>        ret = Curl_input_negotiate(conn, proxy, auth);
>
>      }
>
> in addition to a "neg_ctx->server_name = NULL;" in the "if(GSS_ERROR
(Continue reading)

Permalink | Reply | 7 comments |
headers
Honey Dont | 2 Mar 2009 17:00
Picon
Favicon

Re: Parameters in CURLOPT_WRITEFUNCTION:


--- On Mon, 3/2/09, Daniel Stenberg <daniel <at> haxx.se> wrote:

> 
> You're obviously using the library so I would strongly
> recommend that you use the curl-library mailing list
> instead!
> 

Whoops. Sorry. Wasn't aware of the difference. I have put in for a subscription to the curl-library ml. 

> It doesn't take anything particular into
> "account", it just tells you the size of the data
> and it uses the same argument set that fwrite() offers which
> is why it uses two arguments to specify the size.
> 

Okay. Thanks for this. It makes the function a lot more clear now. But, I can't think of a situation where the
size would be more than 1 for what curl is doing.

      
-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Permalink | Reply | 1 comment |
headers
Robert Baker | 2 Mar 2009 22:57

Re: Trying to download a filled in webpage

Hi Pedro,

When I turn on the debugging, I noticed that in the "Issue another request" it shows the correct location,
But then it displays the "GET/" with  /help/en-ca/browsernotsupported.htm?http%3a%2f%2f
with the rest of the correct path to go to.
Do you know of a way to get around this?
Thanks,
Rob

From: Pedro <phboba <at> gmail.com>
Sent: Friday, February 27, 2009 7:07 PM
To: rbaker <at> bakersoftwaretechnologies.com, the curl tool <curl-users <at> cool.haxx.se>
Subject: Re: Trying to download a filled in webpage


>
> Newbie to curl. be gentle
> I am trying to download a webpage that has been filled in automatically.
> What I have done is sent the correct information to the webpage Which
> in turn displays the result that I want.
> But when I run this command
> curl.exe -o meme
> "http://local.live.com/default.aspx?v=2&rtp=adr.6200%20S%20Main%20street,Ashtabula,OH~adr.4338%20Lake%20Road%20W,Ashtabula,OH"
>
>
> I get the following error,
>
>
>

Object Moved

This document may be found
> HREF="http://maps.live.com/default.aspx?v=2&rtp=adr.62000S0Main0street,Ashtabula,OH~adr.43380Lake0Road0W,Ashtabula,OH">here
>
>
>
> any help would be greatly appreciated
>
> Thanks,
> Rob

Had a similar problem once.
Don't know if it works for you, but try -L

-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Permalink | Reply | 1 comment |

Gmane