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

It is not very magic:

  The only ting the program knows in the beginning is a network address, a port
  that it has to connect via SSL.

  During the SSL handshake, the SSL server certificate contains an extension
  that has the complete URL for the desired service.
 
> > 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.

I disagree. I don't change my mind. I don't consider the https operation
as an atomic one.

It can be somewhat conpared with the the inverse features that exist for example
in apache, where the server, i.e. mod_ssl can alert at the ssl level only
to force client authentification AFTER having seen the URL.

Should an application be required to know the complete URL before
having made the SSL handshake.

Well, curl grooks URLs, so the answer may be yes ...

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

That's why these changes are somewhat dangerous, and
why (I think) we discusss because there is no clearly defined
behaviour.

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

HUHU, anyone else here :-)
>
> > 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.
Good.

>
> > - 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.
I allows me to find arguments :-)

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

I am not against this procedure. If you give me a little bit of time I am happy
to contribute. Indeed, the actual fix proposal can be considered as a dubious
short cut.

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