Fixed for #409 "MultipartBody generates wrong body bytes" and added the ... #410
Conversation
…es" and added the testcase
(Note) This code/patch should be applied after resolving issue AsyncHttpClient#409 "MultipartBody generates wrong body bytes"
| ByteArrayOutputStream output = new ByteArrayOutputStream(); | ||
| Part.sendPart(output, filePart, boundary); | ||
| final ByteArrayOutputStream output = new ByteArrayOutputStream(); | ||
| filePart.sendData(output); |
There was a problem hiding this comment.
Isn't filePart.sendEnd(output); missing there?
There was a problem hiding this comment.
No, filePart.sendEnd(output) is not needed at this line. filePart.sendEnd(output) will be called at initializeFileEnd() --> generateFileEnd().
|
@rlubke Could you review the Grizzly part, please? |
| @@ -78,7 +78,10 @@ public long read(ByteBuffer buffer) throws IOException { | |||
| try { | |||
| int overallLength = 0; | |||
|
|
|||
| int maxLength = buffer.capacity(); | |||
There was a problem hiding this comment.
Actually, I don't think there's a real problem here: the ByteBuffer passed from either Netty and Grizzly providers is a freshly allocated one, so remaining equals capacity. Also, it cannot be negative (it's the chunk size).
There was a problem hiding this comment.
About capacity(), grizzly provider's pure allocation and converting grizzly's Buffer to ByteBuffer doesn't guarantee remaining equals capacity. When I tested the ByteBuffer's capacity is larger than limit(at the pos is 0). If capacity() should be used, maybe ByteBuffer#slice() will be needed after allocation.
For your help, here are grizzly provider's javadoc for Buffer(allocation and converting to ByteBuffer).
/**
* <p>
* Converts this <code>Buffer</code> to a {@link ByteBuffer}.
* If this <code>Buffer</code> is not composite - then returned
* {@link ByteBuffer}'s content is a shared subsequence of this buffer's
* content, with {@link CompositeBuffer} this is not guaranteed.
* The position of the returned {@link ByteBuffer} is not guaranteed to be 0,
* the capacity of the returned {@link ByteBuffer} is not guaranteed to be
* equal to the capacity of this <code>Buffer</code>.
* It is guaranteed that the result of the returned ByteBuffer's
* {@link ByteBuffer#remaining()} call will be equal to this Buffer's
* {@link #remaining()} call.
* The Buffer's and ByteBuffer's position, limit, and mark values are not
* guaranteed to be independent, so it's recommended to save and restore
* position, limit values if it is planned to change them or
* {@link ByteBuffer#slice()} the returned {@link ByteBuffer}.
* <p/>
*
* @return this <code>Buffer</code> as a {@link ByteBuffer}.
*/
ByteBuffer toByteBuffer();
There was a problem hiding this comment.
About negative, I agreed!
Fixed for #409 "MultipartBody generates wrong body bytes" and added the ...
|
@rlubke for your convenience, I will pull a request again for master branch. |
Proposed patch based on ahc-1.7.x branch.
Current sources may be failed in MultipartBodyTest.java so you can reproduce this issue with the testcase.
If you need the patch based on master, please let me know!