On Mon, 28 Jan 2008, Peter Sylvester wrote:

> Indeed. During the establishment of the SSL session one gets informed about
> the real URL, in most cases this would be on the same host. I don't think
> that this is a real redirect or reuse, since the initial URL was not
> completely used for anything (at least not on the HTTP level).

It is regarded a re-use in libcurl's view.

> The effect of not allowing to set an URL during the ssl callback would have
> the effect that one
> has to reestablish a new connection, just because one has changed:
> https://my.server.foo/ or https://my.server.foo/xxx
> to
> https://my.server.foo/service/toto
>
> since during the ssl handshake, the path has not been used, and is not even
> related to a connection, and the "connection part" is the same ...

The "connection" here is in the greater sense, including everything that can
be seen as part of the initial part that isn't repeated for further (possibly
many) requests.

As Gautam Kachroo points out, the reusing of the connection is already broken
in some senses, as the new URL is set and the first transfer is aborted in a
way so that the second use of it (the re-use) accidentally skips stuff that it
shouldn't. This flaw was introduced when the SSL connection was converted to
this non-blocking method.

I've had a look at how easy it would be to fix this bug, but it's a bit of a
pain and since this entire "set a new URL in the SSL callback"-thing is a very
rare use-case I'm now leaning towards simply not supporting this any more.

To recap: It's broken, I don't feel like fixing it and applying Gautam
Kachroo's patch breaks the functionality even more so that test 509 no longer
runs fine.

Or have I missed something important?

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html