Forum Discussion
Ichnafi
Mar 07, 2016Cirrostratus
Hello Kai,
thanks for your reply. The client cert is already in Base64 PEM format, so why double encode it? Why should this brake the insertion, when applying the mentions log statements? Without "log local0. [HTTP::header names]", everything is fine, and the certificate is completely available under the header "X-CLIENT-CERT".
- Kai_WilkeMar 07, 2016MVPI know that the inner body of the cert is already encoded using B64. But the innner body includes also linebreaks that simply destroys your HTTP header. Thats why you have to use a second b64 layer or use URL-Encoding, HEX encoding, or even manually convert the PEM file format to become HTTP/1.1 compliant by inserting SP or HT characters in front of each new line (see RFC2616 4.2). But I guess just applying b64 or URL-Encoding is less complex... Cheers, Kai
- Kai_WilkeMar 07, 2016MVPUpdate: Just created a test scenario by inserting a whole cert into a header. It seems that [HTTP::header insert] already adds the required SP characaters in front of each line. But somehow the [HTTP::header names] command don't follow the RFCs and treat the multi-line value as independent headers. Well, its just the output of [HTTP::header names] that is wrong, but the format of the multi-line header ramains valid after [HTTP::header names] execution and should work for you as long as the backend application is following the RFCs. If the multi-line header still causes trouble on your backend application, then just use b64/URL-encodings to make the value less error phrone (aka. becomming a single-line to avoid edge cases)... Cheers, Kai
- Kai_WilkeMar 07, 2016MVPNote: Feel free to open a [HTTP::header names] bug report... ;-)
- IchnafiMar 07, 2016CirrostratusSo, you mean: 1. [HTTP::header insert ... ] inserts the cert and obviously adds the required SP characters to keep the header RFC conform 2. after that, the log command [HTTP:header names] interprets the header wrong (which is shown in my syslog) but in my case it also alters in some strange way the previously generated header Well.... lessons learned: 1. Talk to the server/application guys and ask them, if they can handle twice B64 encoded certs 2. Don't use [HTTP::header names] for troubleshooting 3. Do a Bug report. Thank you Kai!
- Kai_WilkeMar 07, 2016MVPIt seems in my tests that [HTTP:header names] doesn't corrupts the headers at all. But you may try a "log [b64encode [HTTP::request]]" right before and after executing [HTTP:header names] and then use a b64 decoder of your choice and compare the headers. Cheers, Kai