Anyone else having a problem? A program on one of our user's machines suddenly no longer works, and it looks like it's because their JRE has updated itself.
The program makes a request to a server using a digitally signed, serialized object thusly:
SignedObject so = new SignedObject(request, codeKey, signer);
HttpURLConnection con = (HttpURLConnection)url.openConnection();
con.setRequestProperty("Content-Transfer-Encoding", "gzip");
con.setRequestMethod("POST");
con.setDoInput(true);
con.setDoOutput(true);
ObjectOutputStream out = new ObjectOutputStream(new GZIPOutputStream(con.getOutputStream()));
out.writeObject(so);
out.close();
This interaction has been untouched for some years now. The Servlet handling the request does:
InputStream is = request.getInputStream();
String coding = request.getHeader("Content-Transfer-Encoding");
if (coding != null && coding.trim().equalsIgnoreCase("gzip")) {
is = new GZIPInputStream(is);
log.debug("Request will be de-zipped");
}
ObjectInputStream ois = new ObjectInputStream(is);
Object o = ois.readObject();
ois.close();
Suddenly the user was getting error 400 (invalid request) The server was throwing
java.io.StreamCorruptedException: invalid stream header: 1F8B0800
After a lot of head scratching I noticed he was using rev 22, so I installed it on my own machine and I get the error too. It appears that the Content-Transfer-Encoding header is simply not happening any more. The coding variable in the server is now null. Debugging the sending code calling setRequestProperty no longer adds an entry to the requests field of HttpURLConnection. 1F8B0800 is the "magic number" of a gzip file.
What's going on? This is the second release in a row that's broken existing code (the first by adding a restriction to LDAP search field names).
Later:
I've constructed an SSCE and submitted a bug report on this one. We'll see if anything happens. I'm concerned that pre-release regression testing isn't what it was under Sun.
Edited by: malcolmmc on 29-Oct-2010 20:02