Problem with fix B6369510 for HttpURLConnection Content-Type (original) (raw)

Anthony Vanelverdinghe anthony.vanelverdinghe at gmail.com
Thu Mar 28 11:11:28 PDT 2013

Hello

As far as I can see, SCEP is not an RFC yet, but still an Internet Draft [1]. In Appendix F, it says that a POST message contains "binary PKCS#7 data". It does indeed not mention an explicit Content-Type, but this seems no more than an oversight: the focus of the document is on doing SCEP requests via GET, in which case a Content-Type header is not needed. It 's not because the draft doesn't mention a Content-Type, that it expects the header to not be set. Actually, as the HTTP RFC says, it really should be set: "Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body." [2] Now I don't know what the correct Media Type is for "binary PKCS#7 data", but there is e.g. application/pkcs7-mime & application/pkcs7-signature. And setting it to "application/octet-stream" ought to work anyhow (again from the HTTP RFC: "If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".) As a conclusion, I believe the SCEP draft should be updated to mention the correct Content-Type in case of POST requests.

[1] http://datatracker.ietf.org/doc/draft-nourse-scep/?include_text=1 [2] http://tools.ietf.org/html/rfc2616#section-7.2.1

Kind regards, Anthony

Op 27/03/2013 21:55, Matthew Hall schreef:

But the SCEP RFC expects it to be sent without any header. How is JSCEP supposed to do this if Java overrides it with no way to prevent the override?

More information about the net-dev mailing list