On Tue, 20 May 2003, Peter Sylvester wrote:

(Reply moved over to the libcurl mailing list, to reach more libcurl
hackers.)

> I am experimenting with a small addition to curl which allows to add a
> callback for ssl connections which is called just before creating the SSL
> structure in ssluse.c.

This seems easy and harmless enough to be what other people have requested as
well. Anyone else have any comments on this?

> else
> SSL_CTX_set_verify(conn->ssl.ctx, SSL_VERIFY_NONE, cert_verify_callback);
>
> /* give application a chance to interfere with SSL set up. */
> if (data->set.ssl.fsslctx && !((*data->set.ssl.fsslctx)(data,
> (void *)(conn->ssl.ctx),data->set.ssl.fsslctxp))) {
> failf(data,"error signaled by ssl ctx callback");
> return CURLE_SSL_CERTPROBLEM;
> }
>
> /* Lets make an SSL structure */
> conn->ssl.handle = SSL_new (conn->ssl.ctx);
> SSL_set_connect_state (conn->ssl.handle);
>
> I want to modify the relative part of the url in action, i.e., I initially
> use
>
> https://myhost
>
> and in the server cert I have an extension that tells me
>
> https://myhost/this/service

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?

> unfortunately a call
>
> curl_easy_setopt(p->curl, CURLOPT_URL, service);
>
> doesn't work at that place, since the url is already parsed.

Yeps.

> Well, since I don't give up so easily:
>
> In http.c there is the following code:
>
> if (data->change.proxy && *data->change.proxy &&
> !data->set.tunnel_thru_httpproxy &&
> !(conn->protocol&PROT_HTTPS)) {
> /* The path sent to the proxy is in fact the entire URL */
> ppath = data->change.url;
> }
>
> Is it really necessary to make all the tests.

Feel free to suggest improvements...

> the url send an http host can be the full URL. I tried to set the ppath
> unconditionally, the code works.

No. The path used a GET line to a typical HTTP server shall not be the full
URL, only the path part. Only proxies get the full URL in there. Your test
server might not complain, but we cannot do that serious violation against
the RFC. Others will not appreciate that.

When you do changes like this, I suggest you re-run the test suite to verify
that your changes at least didn't break any of the tests we have crafted.
They don't cover all of (lib)curl's functionality, but they're a good
indicator.

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