-----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

Reply via email to