-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Michael,
On 06/21/2013 10:08 AM, Michael Chen wrote:
> Hi Marc,
>
> A bug in my program sent the following multi-part header followed by the
> pkcs10 DER binary, but your server ignored the transfer encoding header and
> processed the csr:
>
> --0xD2454C4F Content-Disposition: form-data; name="csr" Content-Type:
> application/pkcs10 Content-Transfer-Encoding: base64
>
> <CSR DER binary>
>
> --0xD2454C4F
>
> RFC2311 (referenced in section 11.3 of p2psip-base) does describe the use
> of base64 encoded application/pkcs10 content type (3.7.2). The p2psip-base
> draft should either endorse or explicitly exclude the base64 encoding
> stated in RFC2311.
>
Hmm, RFC 2616 states in section 19.4.5:
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
remove any non-identity CTE ("quoted-printable" or "base64") encoding
prior to delivering the response message to an HTTP client.
On the other hand RFC 2388 has an example using CTE:
--AaB03x
content-disposition: form-data; name="field1"
content-type: text/plain;charset=windows-1250
content-transfer-encoding: quoted-printable
Joe owes =80100.
--AaB03x
Perhaps what RFC 2616 meant was that CTE cannot be used as an header, but can
be used as a MIME parameter. But as HTTP never had any 7bit/8bit issues, I
doubt it.
For the sake of interoperability, I filled a bug to add support for CTE in
form-data my server.
- --
Marc Petit-Huguenin
Email: [email protected]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJRxJKPAAoJECnERZXWan7EFHUP/3LFuKBZ/mQZRVfIvlVUR4g0
6ZGrXMmZ0szR/S1LGBtN2Rwp/UdLqGo1EN0rP75ZtGQefJJ3MzMbFi6mE4kgPOLj
cthl11+SbbpJKUDL8MJHGWrMsYUPX0DASs7+Si/nqKCigm4INkhkOngnoB4D5x6N
DetwUvbsmnmxejwWbiOTQ0YdHSI1F4el8R4T6S3cRgGCHSNKADP0fd7T14mxYPpH
1Lgnr4WI6jczovLl//314S45g7vgSvMUtiRkjURON6lLD1GTb+6/sB9yTZ0lftEe
qxRXRf226VHVyVHjgEh+giCSCpDCbql8ny+q43IFZWtoMv4IXo+NiTiMALwIvfwp
NmmYObyFrbEjZC582xV2rIZSF/MgWad91p0BChwQ0gP7PaxkMQdZWqK1Uv58aszZ
AW+6YGu9yhzmoi9FO3uFLlab+wElD4JiNHj7BdbbghJW2Pkcrubg0uj4OJoqSuYM
uj4Ilj9IJtf4BGG1aOBM2SS+feIXhVomAVW9JiW9x3mqAMErSzoYjT7bR5Vgtxbo
c20sviT3lYp2bGqPPAUNz+85adsMaz6gIZyzaGsivQnk4zI/uwxkaSj0NUXzoOgv
VDLk/yo1KfDx+r6NTP3PIgpLW3nfLvHDw/8rGPeLhLNVMW8HOp5HrBHAeJDbGGIW
2xpEV4fpnTZZ/3zpI0gi
=WhEI
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip