-
Notifications
You must be signed in to change notification settings - Fork 216
Description
Hi,
it seems to me that there is an issue and the server is not compliant when an artifact is not loaded at once, but using byte-range (delta update). I have found a discrepancy compared with distro Webservers like Apache or Nginx, where I could load and parse chunks without problems.
In RFC 1341, CRLF are used to identify the end of a header and the end of all headers.
The boundary must be followed immediately either by another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part (and it is therefore assumed to be of Content-Type text/plain).
However, this doesn't seem the case for Hawkbit. If I downloaded bytes ranges with curl (so without my implementation), I see 👍
--THIS_STRING_SEPARATES_MULTIPART
<CRLF>
Content-Range: 557755-558177/83071720
<CRLF>
<start of data>
So "THIS_STRING_SEPARATES_MULTIPART" is the boundary used by Hawkbit. However, the second "CRLF" that means "end of headers" is missing, causing that parser (I use very broadly code that works flawlessly with Apache / Nginx / ..) starts to consider it as an additional header, that is not solved because it is not.
Checking into the code, it seems that a CRLF is missing in handleMultipartRangeRequest (file FileStreamingUtil.java):
for (final ByteRange r : ranges) {
try (InputStream from = artifact.getFileInputStream()) {
// Add multipart boundary and header fields for every range.
to.println();
to.println("--" + ByteRange.MULTIPART_BOUNDARY);
to.println(HttpHeaders.CONTENT_RANGE + ": bytes " + r.getStart() + "-" + r.getEnd() + "/"
+ r.getTotal());
==> end of Headers is missing
// Copy single part range of multi part range.
copyStreams(from, to, progressListener, r.getStart(), r.getLength(), filename);
Can someone verify my assumptions ?