> From daniel_at_haxx.se Wed May 21 10:31:40 2003
> Date: Wed, 21 May 2003 10:31:36 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> X-X-Sender: dast_at_linux3.contactor.se
> To: Peter Sylvester <Peter.Sylvester_at_EdelWeb.fr>
> cc: libcurl Mailing list <curl-library_at_lists.sourceforge.net>
> Subject: Re: ssl callback
> MIME-Version: 1.0
> Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII>
> Content-Length: 3134
>
> On Tue, 20 May 2003, Peter Sylvester wrote:
>
> > The initial reason for request is that I have a key, a user cert and a
> > trustbase available as a PKCS12 file. Adding a callback at SSL creation is
> > a real hammer and may not be the most elegant way since it adds more
> > dependency towards openssl.
>
> Yes, I agree that it isn't very library-agnostic or anything, but I still
> think adding flexibility with the current only library we support is better
> than not doing it at all.
>
> When we get other SSL-libraries supported, we can dig more into this problem.
>
> > An option could be to allow keys also coming from "memory" in whatever way.
>
> Since this is just a callback, your provided callback can of course have the
> key whereever it wants, on disk or in memory.

Yes. That is the purpose 1 of the callback.
 
> > > I'm sorry, I don't understand. Why do you set one URL first and then you
> > > want to change it before the first was ever used? Why not just set the
> > > full one at once?

Because the first 'URI' is not a complete one. It only allows to connect to the
right host and to start the ssl handshake. The URL may be valid but
the handshake I may learn a better one.

> >
> > The first is actually not an URL but only a host. I don't have the exact
> > URL at the moment when th connection is established. The usage if this in
> > our project is not a real problem but one other usage would be in a
> > "sacred" environment where you have a PKCS11 module and the user types
> > "host:login" to connect to a authentication server to download his
> > credentials.
>
> I still don't understand your request.

The request is that I'd like to have setopt(CURL_OPT_URL) work to some
degree after the initial URL cleanup had been done (for a subset of
URLs, i.e. https etc).

>
> In this case, you'd first request the url https://user:pasword@host/.

  That's not the request at all in this case:

  host:login determines essentially the first message in for example an SRP
  protocol, i.e. the host to connect to and the login of the user, of course
  the user could initialy type the full URI of its credential server but
  well, why asking them to do to much if one can discover some things
  automatically.

  Of course, on can always make a complete request to this "welcome" page
  and then do a second one later.

  Indeed, with a persistant connection, the penality is not that heavy, but
  loading always a useless page is not extremely elegant.

> >
> > HTTP 1.1 servers MUST accept the absoluteURI. See page 37 of RFC 2616.
>
> You oversimply things here.
Yes. :-)

Since I agree in principle with your concerns, I don't repeat them.

>
> o Having libcurl parse the URL before using it has its advantages, and we're
> already taking use of that in a few places: it can correct commonly used
> misuses of URLs and make the correct one used to the server. This is what
> browsers do and that people expect curl to do as well.

That's ok. But it seems that the actual code assumes that

- You set an URL
- A connection is established or reused, the
  first step is to parse and correct the URL, then
  find the host etc and then the connnection is esatblished.
  At that points, nothing of the URL cannot be modified anymore
  (unless you have a HTTP proxy).

- The appropriate portion of the URL is send for the
  protocol.

During the session establishment, actually nothing
can be done to modify a HTTP URL except when you pass
through an http proxy. In this case the CURL_SETOPT_URL
works, since the data->change.url is taken directly, and
the conn->ppath may not reflect at all the actual URL.

To resume, it seems there are at least two issues.

- It seems that in principle a call back done at an
  appropriate place during SSL initialisation doesn't
  create philosphical problems :-)
  
  If other SSL libraries will be supported then there
  is most likely always an object that represents some
  SSL context in whatever way,

  The application needs to be coded in a way specific
  to the particular SSL library and some knowledge of
  the context object.

- The second problem is the question whether it is
  allowed, possible, desirable etc to modity the
  actual URL during some session establishment.
     

regards
Peter

-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
Received on 2003-05-21