On Mon, May 05, 2014 at 01:56:37PM +0400, Ruslan Ermilov wrote:
> On Sun, May 04, 2014 at 03:44:47PM +1000, Matt Palmer wrote:
> > The below patch is a small one, to make the common use-case for
> > $ssl_client_cert (including it in an HTTP request header)
> > protocol-compliant. Some receiving webservers don't like a plain '\n' in
> > the requests they receive.
> >
> > I considered digging deeper to find a more "natural" place to ensure
> > protocol compliance, but then I figured that since we're *already* mangling
> > the "native" look of the PEM data (adding leading tabs), adding some '\r'
> > wasn't a huge further leap.
> >
>
> Better use macros CR and LF instead of '\r' and '\n'.
> Otherwise, your patch looks good to me.

OK then, take 2:

-----8<-----
Properly escape $ssl_client_cert for HTTP protocol compliance

The common use-case for $ssl_client_cert (including it in an HTTP request
header) means that each line should be terminated with CRLF, rather than
just a plain LF. Some receiving webservers really don't like a plain LF to
terminate lines.

--- a/src/event/ngx_event_openssl.c
+++ b/src/event/ngx_event_openssl.c
@@ -2615,7 +2615,7 @@ ngx_ssl_get_certificate(ngx_connection_t

for (i = 0; i < cert.len - 1; i++) {
if (cert.data[i] == LF) {
- len++;
+ len += 2;
}
}

@@ -2628,9 +2628,12 @@ ngx_ssl_get_certificate(ngx_connection_t
p = s->data;

for (i = 0; i < cert.len - 1; i++) {
- *p++ = cert.data[i];
if (cert.data[i] == LF) {
+ *p++ = CR;
+ *p++ = LF;
*p++ = '\t';
+ } else {
+ *p++ = cert.data[i];
}
}


- Matt

--
Sure, it's possible to write C in an object-oriented way. But, in practice,
getting an entire team to do that is like telling them to walk along a
straight line painted on the floor, with the lights off.
-- Tess Snider, slug-chat@slug.org.au

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel