binary.toByteString() doesn't correctly handle byte arrays #439
Labels
Comments
grob
added a commit
to ringo/stick
that referenced
this issue
Nov 6, 2021
(see ringo/ringojs#439) to construct the etag md5 digest it copies the response body into an array of byte arrays/byte strings, but `Stream.forEach()` re-uses a single binary buffer [1], so if the streamed response exceeds 8192 bytes and thus be split up into multiple buffers the body created by etag middleware would essentially consist of different byte arrays all containing the same bytes. the fix is to use `Binary.prototype.slice()` to copy the body part - this is expensive and effectively thwarts the use of `response.stream()`, but it's what the etag middleware did before #409 too, and at least it doesn't corrupt binary responses anymore. [1] https://github.com/ringo/ringojs/blob/master/modules/io.js#L48
|
I think we should stick to the current behavior and introduce additional checks were the type of an object is not determined. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
binary.toByteString() correctly checks if the argument is a Binary instance (which is true for ByteArray instances), but then calls toByteString() with source and target charsets. This creates a String based on the ByteArray using the source charset (default: utf-8), and a new Binary instance using the target charset (utf-8).
The effect is that stick's etag middleware (which uses binary.toByteString()) breaks responses consisting of ByteArrays, but works fine if the charset arguments in binary.toByteString() are removed.
Possible solutions: either re-apply the check introduced in 8edcb927846a in etag middleware, or remove the charset arguments here - but i'm not sure if the latter would be safe to do
The text was updated successfully, but these errors were encountered: