> Yes, that is what I'm suggesting. 0 or 2. With 1 then getting treated as > illegal which internally will cause it to equal 2. (Within libcurl the value > becomes a plain simple boolean though.) ... > However, introducing these names *now* will also make users of the new > defines not being able to copy their source code back to building with older > libcurl headers so the documentation needs to be very clear on this part.
> Possibly we could use these names: > CURLVERIFYHOST_IGNORE (0) > CURLVERIFYHOST_PROPERLY (2 - default) I prefer CURLVERIFYHOST_SECURE for this value. > All other values are considered illegal and will be ignored. I suggest the following: 1. Making '1' a deprecated value - make it act as CURLVERIFYHOST_SECURE, while issue a warning (but don't return CURLE_BAD_FUNCTION_ARGUMENT). 2. Announce that '1' will become illegal value by DD/MM/YYYY (Daniel - I left this to you as). The reasons are: * It will give time to all applications that use '1' by mistake (and we think this is the most common situation) to change their code, while still work with the new curl distribution. * New code that is written, probably, would use the new values (CURLVERIFYHOST_SECURE/IGNORE) so we keep it working with old curl versions. I think this is the golden trail when considering 'backward compatibility' and 'defensive code' values, which, I believe, are both important in the curl spirit. I don't think we should even consider SONAME change for this issue (I don't think the behavior of checking the existence of CN in the subject, is someone in production environments really need). Yehezkel Horowitz ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
