"Daniel Stenberg" <daniel-curl_at_haxx.se> said:

> I was under the impression that this limited wildcard support was somehow
> mandated by an RFC, but when I try to find evidence for this I fail miserably.

RFC-2818, section 3.1:

 ... Names may contain the wildcard character * which is considered to
match any single domain name component or >> component fragment <<.
E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches
foo.com but not bar.com.
 
> This also makes be wonder if they could also contain more than one wildcard,
> as in 'www*.h*xx.se' ?

Don't think so (it doesn't mention component fragment*s*).

> I think the current *DATA_* should be for the data that the app sends/gets, so
> I think I would prefer a CURLINFO_SSL_DATA_x for additional SSL data to get
> shown.

Okay, but for HTTP chunked encoding, CURLINFO_DATA_IN does not contain
the dechunked data. Not sure where exactly the division of application data
should be. SSL handshake also belongs in the app. layer, but maybe a debug-
callback could be confused by such data?

I'm not happy with the curl_debug_callback prototype either. It could be a
var-arg function for better versatility. So in the SSL callback it could do
  Curl_debugf (data, CURLINFO_SSL_DATA_OUT, ssl_buf, len, "SSLv%d, ...);

which is picked up in curl and printed as:
=> Send data SSLv2, Client hello (1):, 130 bytes (0x82)
0000: 01 03 01 00 69 00 00 00 10 00 00 39 00 00 38 00 ....i......9..8.

(and not one line info and a data block).
This wouldn't break old programs if we put an "const char *extra_fmt, ..."
at the end. Would it?

BTW. is there any reason Curl_debug(..., char *data..) isn't a const?
Modification of data in the debug handler :)

--gv
Received on 2004-06-14