Interoperability issue between JSCEP client and Sun HttpURLConnection Implementation #1

Closed
megahall opened this Issue Mar 27, 2013 · 1 comment

Comments

Projects
None yet
2 participants
Member

megahall commented Mar 27, 2013

Hello,

I discovered an interoperability problem between the JSCEP Client and the JDK.

The HttpURLConnection implementation contains some code like this:

if (!method.equals("PUT") && (poster != null || streaming()))
requests.setIfNotSet ("Content-type", "application/x-www-form-urlencoded");

The JSCEP Client does not set Content-Type on the POSTs it makes to the SCEP server.

Because the Content-Type is force-set by the implementation code, Tomcat and other servlet containers will attempt to decode and process the data as if it were URL encoded. But because it's actually binary SCEP data this is going to fail, and when it does, Tomcat deletes the POST body from its own Request objects, which makes it impossible to handle the request in the server side.

Unfortunately the SCEP RFC draft does not specify what Content-Type to use when performing the POST upstream.

I did report the JDK's bug to Oracle here:
http://mail.openjdk.java.net/pipermail/net-dev/2013-March/005918.html
http://mail.openjdk.java.net/pipermail/net-dev/2013-March/005919.html

But that will probably take a long time to get addressed. So I am hoping it would be possible to request a new version of JSCEP, which allows some way to set the Content-Type to be set from outside, so I could try different values, to find one which is interoperable across both sides, or, at least, try setting it to application/x-pki-message .

Thanks,
Matthew.

@ghost ghost assigned seize-the-dave Mar 27, 2013

Contributor

seize-the-dave commented Mar 27, 2013

RFC 2616 appears to recommend "application/octet-stream":

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. 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".

From http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment