On Fri, Nov 25, 2016 at 12:58 PM, Maxim Dounin <mdou...@mdounin.ru> wrote:
> > 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. > Well, ok, mine worked out of the box, because the server changed newlines to spaces before I got the value in my application. I'm using Jetty, which is quite popular in Java circles, so I suspect a lot of people would be unsurprised to find the newlines replaced by spaces, like you suggested. And we already use URL encoding in out mail module, so the are > good reasons to keep things consistent. > Yes, that's true. > 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. > Yes, I think I did find a comment somewhere that said that openssl wanted a max line length. > 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. >From where I sit it looks like this problem was reported about a year ago without any solution being merged, so I just want try to help things along. > 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. > I agree wholeheartedly. So at least urlencoded variant is needed ($ssl_client_escaped_cert?). Yes, and at least it's consistent with the other solution as you noted. 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. > I'm afraid I don't know what this means, care to elaborate? Do you mean people who simply set a header to $ssl_client_cert? 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. > I'd be very happy with this as the only change as my server already gives me exactly this value when I ask for the header, so my application would not even notice the change. -- Flemming Frandsen - YAPH - http://osaa.dk - http://dren.dk/
_______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
