On Thu, 5 Jun 2003 07:43 am, Daniel Stenberg wrote:
> I'm sorry I didn't express myself clear:
>
> libcurl is a rather low-level library and I intend to keep it dependent on
> as few libraries as possible (mainly only libraries that provide features
> for the transport protocols that makes better sense than to rewrite them
> ourselves). I do not think regexes of ANY kind are necessary for libcurl's
> operations and I will not accept code that use such libraries into the main
> libcurl source tree.

'Here here' - apart from bloat, it would only add pain trying to integrate
libcurl with anything already using it's own regexes, or requiring a specific
pcre version - e.g. perl itself, apache, php.

> Then I'd suggest one of these alternative approaches:
>
> A) We add (yet another) callback to libcurl that allows the application to
> provide the name check. Possibly, the callback function for certificate
> verification that is in the works by Peter Sylvester could also do that.
> Any details on this Peter?
>
> When this is made, we could make the curl tool support whatever regex
> library we think is fit. I still think it is overkill.

I vote +1 for this one! A callback at ssl handshake time can do whatever weird
checks people can dream up.

If the callback can breakout/decode common certificate parameters, I guess
that would simplify the job for clients...

> B) We offer a list of host names to the libraary, where one of the given
> names may match.

I think this might be what the curl tool shoulddo if it used the above
callback - provides pretty much all you need, but still keeps regexes out of
the library and tool.

Cheers,
Cris

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
Received on 2003-06-05