On Tue, 15 May 2012, Daniel Stenberg wrote:

> > I've not really looked too much at what you have done with the
> > callback but I think all that I would need is a way of specifying
> > which mechanisms are available from the server to the callback and as
> > the programmer which mechanisms I want libcurl to use for my
> > application. Both of these arguments could be implemented as either a
> > bitwise numerical value or as a list of mechanisms in order of
> > preference - For example the server may tell me that GSSAPI is
> > preferred, followed by NTLM and then PLAIN. I may want to tell libcurl
> > that my preference is PLAIN followed by GSSAPI - and yes I would be
> > mad to do this but hopefully you get my point ;-)
>
> Joe's current suggestion doesn't really support that as libcurl doesn't
offer
> that functionality. The callback currently simply gets to know which
> method libcurl has selected to use, based on the bitmap the application
> initially set it could select from.

Ah right...

> For HTTP we've not yet found a user who suffered from this design choice,
> even though I know we've discussed it for SMTP/POP3 already - although
> I'll admit I'm not sure I understand (or did I just forget?) in which
situations
> a user would prefer an alternative order.

I must admit I'm not too sure there is a legitimate reason to do it at the
moment. In the SMTP world a server would typical respond with:

250-AUTH GSSAPI NTLM LOGIN

I believe the preference is left to right, so if an application supports
GSSAPI then it should use that, if not then NTLM etc...

Likewise in POP3 a client would issue the AUTH command and the server would
reply with:

+OK
GSSAPI
NTLM
PLAIN
.

Again I believe the order is top to bottom - although my Exchange server
just replied with GSSAPI and NTLM the other way round!!

The current SMTP implementation performs the selection based on what we
think is the most secure ;-) I think this needs to change to honour what the
server has told us, however, I'm not too sure whether there is a valid use
case for an application using curl to override that and say actually, I want
to use NTLM before GSSAPI (in the above examples).

> This said, I really want this callback to be designed to work for
virtually any
> protocol libcurl supports even if the initial work is limited to HTTP. I
think
> you (Steve) is in a good position to provide good feedback on this since
> you're one of us who'd doing the most fiddling in the POP3/SMTP areas.
>
> I guess a step forward would be to write a test application source code
> using this new API and see if it could be mapped well on
> FTP/IMAP/POP3/SMTP too concept-wise.

Yes... It's probably a good idea for me to take a look at Joe's work and see
if I can get something together for SMTP.

Kind Regards

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-05-16