Problem with fix B6369510 for HttpURLConnection Content-Type

[Anthony Vanelverdinghe]

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?