adoptium-support
adoptium-support copied to clipboard
HTTP/1.1 header parser received no bytes.
Hi, the same exact code works well with Adopt JDK15 but not on Adopt JDK16
HttpRequest request = HttpRequest.newBuilder()
.header(Constants.UPGRADE_CONTENT_TYPE, Constants.UPGRADE_MULTIPART + boundary)
.POST(ofMimeMultipartData(data, boundary))
.uri(URI.create(Constants.UPGRADE_URL.replace(Constants.DASH, glowWormDevice.getDeviceIP())))
.build();
client.send(request, HttpResponse.BodyHandlers.discarding());
/**
* MimeMultipartData for ESP microcontrollers, standard POST with Java 11 does not work as expected
* @param data data to be transferred
* @param boundary boundary
* @return body publisher
* @throws IOException something bad happened in the connection
*/
public static HttpRequest.BodyPublisher ofMimeMultipartData(Map<Object, Object> data, String boundary) throws IOException {
var byteArrays = new ArrayList<byte[]>();
byte[] separator = ("--" + boundary + "\r\nContent-Disposition: form-data; name=").getBytes(StandardCharsets.UTF_8);
for (Map.Entry<Object, Object> entry : data.entrySet()) {
byteArrays.add(separator);
if (entry.getValue() instanceof Path) {
var path = (Path) entry.getValue();
String mimeType = Files.probeContentType(path);
byteArrays.add(("\"" + entry.getKey() + "\"; filename=\"" + path.getFileName()
+ "\"\r\nContent-Type: " + mimeType + "\r\n\r\n").getBytes(StandardCharsets.UTF_8));
byteArrays.add(Files.readAllBytes(path));
byteArrays.add("\r\n".getBytes(StandardCharsets.UTF_8));
} else {
byteArrays.add(("\"" + entry.getKey() + "\"\r\n\r\n" + entry.getValue() + "\r\n").getBytes(StandardCharsets.UTF_8));
}
}
byteArrays.add(("--" + boundary + "--").getBytes(StandardCharsets.UTF_8));
return HttpRequest.BodyPublishers.ofByteArrays(byteArrays);
}
Using JDK16 I get this error:
HTTP/1.1 header parser received no bytes
Any idea on how to fix it? Is this a JDK problem?
Using same code on JDK 15 works well.
We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable. It will be closed soon unless the stale label is removed by a committer, or a new comment is made.
https://bugs.openjdk.java.net/browse/JDK-8239117
We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable. It will be closed soon unless the stale label is removed by a committer, or a new comment is made.
Bad bot
We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable. It will be closed soon unless the stale label is removed by a committer, or a new comment is made.
We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable. It will be closed soon unless the stale label is removed by a committer, or a new comment is made.
We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable. It will be closed soon unless the stale label is removed by a committer, or a new comment is made.
We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable. It will be closed soon unless the stale label is removed by a committer, or a new comment is made.
Should be fixed in https://bugs.openjdk.org/browse/JDK-8299018
And 17.0.7 as as backport.
@sblantipodi Can you test and get back to us?
My bad, might not be, actually (I reproduced a similar bug with jdk 21).
Ref:
- https://bugs.openjdk.org/browse/JDK-8239117
- https://bugs.openjdk.org/browse/JDK-8326420