Hello! On Thu, Nov 24, 2016 at 08:57:35PM +0100, Flemming Frandsen wrote:
> Yes, that's correct, but: > > 1: You'd need custom code to url decode the header anyway and ignoring lack > of newlines is simpler. URL decoding is available out of the box in most environments. That is, recovering original PEM is as simple as wrapping a reference to a header into a function call. > 2: No existing parser will handle url decoding of the header without > changes, but some might work without the newlines. You may want to name a few. And we already use URL encoding in out mail module, so the are good reasons to keep things consistent. > 3: You don't need to recover the original PEM format as newlines are > optional for any reasonable base64 parser. They aren't optional at least for OpenSSL itself. > If anything, it could be argued that the -----BEGIN CERTIFICATE----- and > -----END CERTIFICATE----- bits should be removed too as that's of no use to > the base64 decoder and has to be removed to get started parsing the actual > content anyway. > > Without the begin and end bits someone who is really interested in getting > a complete PEM file out of the header could very easily slap the start and > end lines around a line-wrapped base64 content. Such approach was already considered when working on the mail implementation of client certificates support. Essentially, this provides Base64-encoded certificate in DER format. This is certainly better than just removing newlines, yet urlencoding is considered to be better in most cases. > If you're really unhappy with my proposed solution, then I can try to fix > up the url encoding patch that was posted earlier, though I still think > it's silly to go to such lengths to preserve newlines that nobody wants. There is no problem with preparing any patch. And there were already quite a few. The main problem here is naming things: that is, how things are expected to be named in the future, and how transition is expected to look like. The situation when $ssl_client_cert variable is not usable in most if not all cases looks at least strange. We probably need to switch it back to original meaning of PEM-encoded certificate (now available as $ssl_client_raw_cert). And it would be enough if we have some trivial functions like urlencode/urldecode available (see ticket #52) - but, unfortunately, we don't have them now. So at least urlencoded variant is needed ($ssl_client_escaped_cert?). And the next question is what to do with current $ssl_client_cert, as we need to preserve compatibility at least somehow for people who currently use certificate with tabs added as a multiline header. Another possible approach might be to change $ssl_client_cert to use spaces (tabs?) instead of newline + tab. This should be compatible with what most servers provide as a result of parsing multi-line header, and implies less changes. This needs an additional investigation though. -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
