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.

> > 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?
>
> 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.

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

If you'd need a second URL after this, then fine, request that URL after
this. Due to persistant connections and session ID caching, there is very
little penality for doing a second request.

I would much rather enforce this not-too-awkward policy than start making
weird modifications to the library.

> > No. The path used a GET line to a typical HTTP server shall not be the full
> > URL, only the path part.
>
> HTTP 1.1 servers MUST accept the absoluteURI. See page 37 of RFC 2616.

You oversimply things here.

o While of course HTTP 1.1 server MUST obey the RFC2616, not all
  servers do. Having curl taking this huge step into taking advantage of a
  major difference in what HTTP 1.0 and 1.1 require will make curl fail in
  several occations, I'm pretty sure. It is not "being conservative in what
  we send".

o How can we tell that the server is actually a 1.1-server before we've read
  the reply?

o What if you do this operation on a 1.0-server?

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.

o What if the new URL has a new host name and/or port number and/or user
  name and password?

o Also, we must consider the impact such an operation would have on other
  protocols libcurl operates on, such as FTP.

> The suggested solution is to just avoid a recalculation of conn->ppath
> whenever one sets a URL.

I am not convinced that a second URL is needed or that all my worries above
are void.

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
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