Hi daniel >My only concern with the added ifdefs for the memory handling is that the source code seems to imply that it can work with both gssapi and spnego present at the same time and then it isn't correct to select the method at compile-time but it should instead be decided in run-time.
>Do you agree? Yes daniel I agree. Actually fbopenssl's job is to convert negotiate tokens from one format to another(typically gssapi standard to spnego). They cater to different rfcs. SPNEGO is the one used in all http communication. For example my server is a tomcat implementation which only accepts SPNEGO tokens. So in the event the code is compiled with HAVE_SPNEGO as a preprocessor directive, the SPNEGO operation builds on top of the gssapi one. In other words, if both are together, only SPNEGO token goes to server. Now neg_ctx->output_token.value = spnegoToken.value; neg_ctx->output_token.length = spnegoToken.length; happens in spnego compiled code in case fbopenssl succeeds in the conversion. Thus the variable contains spnego token which was allocated using standard malloc(). If not compiled, it contains standard gssapi token not allocated by malloc. Hence the patch is also designed the same way. In spnego is done, the spnego token (neg_ctx->output_token.value) is always malloced and hence must be freed equivalently. I hope this dispels your concerns Yours sincerely -- Arunav Sanyal Graduate student B.E (Hons) Computer Science BITS Pilani K.K Birla Goa Campus Software Engineer INFORMATICA BUSINESS SOLUTIONS
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
