On Wed, 21 May 2003, Peter Sylvester wrote:

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

But does your program "discover" the rest of the URL magically after the SSL
callback? How come your program doesn't know the full path when you start
connecting to the site, and then all of a sudden finds out?

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

No, I agree with you this isn't the most elegant way one can imagine, but we
have to weigh that against the crudeness of the hack necessary to make
libcurl support this "change of mind" in the midst of the operation.

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

Changing the URL when you operate against a proxy is not entirely working
either, at least the Host: header will be wrong if you change host name or
port number.

> 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 :-)

Nope, at least not in my mind, and so far this issue only seems to be your
view and my view with no other parties airing any opinions.

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

Yes.

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

Thanks for being patient with my resistance on this point.

If it is really necessary for you to do this, then I think we should make an
effort to get it to work. But I don't like to make too many shortcuts, so if
we are to allow CURLOPT_URL being set during the transfer (after
curl_easy_perform() is called and before it returns) we should re-parse the
new URL and use the pieces accordingly, and we need to document clearly what
can be expected behavior when such an action is done. We also need to be able
to refuse to set a new URL, as in when the current one is already in use
(like for ftp).

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