<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 25, 2016 at 12:58 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote: <span class="gmail-"></span><br><span class="gmail-"></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> 2: No existing parser will handle url decoding of the header without<br>
> changes, but some might work without the newlines.<br>
<br>
</span>You may want to name a few.<br></blockquote><div><br></div><div>Well, ok, mine worked out of the box, because the server changed newlines to spaces before I got the value in my application.<br></div><div><br>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.<br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And we already use URL encoding in out mail module, so the are<br>
good reasons to keep things consistent.<br></blockquote><div><br></div><div>Yes, that's true.<br></div><div> <span class="gmail-"><br><br></span><span class="gmail-"></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> 3: You don't need to recover the original PEM format as newlines are<br>
> optional for any reasonable base64 parser.<br>
<br>
</span>They aren't optional at least for OpenSSL itself.<br></blockquote><div><br></div><div>Yes, I think I did find a comment somewhere that said that openssl wanted a max line length.<br></div><div> <span class="gmail-"></span><span class="gmail-"><br><br></span><span class="gmail-"></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> If you're really unhappy with my proposed solution, then I can try to fix<br>
> up the url encoding patch that was posted earlier, though I still think<br>
> it's silly to go to such lengths to preserve newlines that nobody wants.<br>
<br>
</span>There is no problem with preparing any patch.  And there<br>
were already quite a few. </blockquote><div><br></div><div>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.<br></div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> The main problem here is naming things:<br>
that is, how things are expected to be named in the future, and how<br>
transition is expected to look like.  The situation when<br>
$ssl_client_cert variable is not usable in most if not all cases<br>
looks at least strange.<br></blockquote><div><br></div><div>I agree wholeheartedly.<br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So at least urlencoded variant is needed ($ssl_client_escaped_cert?).</blockquote><div> <br></div><div>Yes, and at least it's consistent with the other solution as you noted.<br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And the next<br>
question is what to do with current $ssl_client_cert, as we need<br>
to preserve compatibility at least somehow for people who<br>
currently use certificate with tabs added as a multiline header.<br></blockquote><div><br></div><div>I'm afraid I don't know what this means, care to elaborate?<br></div><div>Do you mean people who simply set a header to $ssl_client_cert?<br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Another possible approach might be to change $ssl_client_cert to<br>
use spaces (tabs?) instead of newline + tab.  This should be<br>
compatible with what most servers provide as a result of parsing<br>
multi-line header, and implies less changes.  This needs an<br>
additional investigation though.<br></blockquote><div><br></div><div>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.<br></div></div><br>-- <br><div class="gmail_signature">Flemming Frandsen - YAPH - <a href="http://osaa.dk" target="_blank">http://osaa.dk</a> - <a href="http://dren.dk/" target="_blank">http://dren.dk/</a></div>
</div></div>