You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
(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
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: