<div dir="ltr"><div><div><div>Yes, that's correct, but:<br><br></div>1: You'd need custom code to url decode the header anyway and ignoring lack of newlines is simpler.<br></div><div>2: No existing parser will handle url decoding of the header without changes, but some might work without the newlines. <br></div>3: You don't need to recover the original PEM format as newlines are optional for any reasonable base64 parser.<br><br></div>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.<br><div><br></div><div>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.<br><br></div><div>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.<br></div><div><br><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 24, 2016 at 2:39 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Thu, Nov 24, 2016 at 02:15:17PM +0100, Flemming Frandsen wrote:<br>
<br>
> Hi, I've been bitten by issue 857: <a href="https://trac.nginx.org/nginx/ticket/857" rel="noreferrer" target="_blank">https://trac.nginx.org/nginx/<wbr>ticket/857</a><br>
><br>
> I terminate TLS in nginx, but I need access to the full client certificate<br>
> in the backend, so to that end I've been using $ssl_client_cert, but now<br>
> I've upgraded the application to a version that is RFC 7230 compliant and<br>
> that means blowing up when multi-line headers are seen.<br>
><br>
><br>
> As there's no reason to have newlines in a PEM file, my fix for #857 is to<br>
> remove all the newlines, as my PEM parser in the application already<br>
> ignores all newlines this works perfectly for me.<br>
><br>
> I think simply removing the newlines is a much better solution than url<br>
> encoding the newlines as less code (in my case none at all) is needed to<br>
> deal with no newlines than urldecoding.<br>
<br>
</span>The problem with removing newlines is that it requires custom code<br>
to recover original PEM format.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
<br>
______________________________<wbr>_________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-devel</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="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>