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
Looks like any image url that returns an compressed response from the server does not work. The error in the console is:
image resource service: Invalid argument(s): source array is too long
I understand that web-Support is listed as limited due to no caching, but I guess it should at least load the image with that "limited support", as Image.network(...) also does it just fine. Compressing server responses should be a common thing, and often times cannot even be switched off on server platforms.
My best guess: Maybe that the Content-Length Header is used to create some kind of buffer for the image but this header only provides the number of bytes of the body after compressing it. Using this number anyway would result in a buffer that is too small, which would explain the message. I did not figure out a way to debug this any further yet, so this really is just a guess, but maybe it helps.
I encountered this error for gzip and brotli (br) compression. Disabling the compression makes it work.
Expected behavior
Expecting to see an image but getting an error widget instead.
Reproduction steps
Load any image that is delivered by the server using some kind of compression (e.g. gzip or brotli/br).
Configuration
Version: 3.3.1
Platform:
馃摫 iOS
馃 Android
馃寪 Web
The text was updated successfully, but these errors were encountered:
quaaantumdev
changed the title
Web not working with simple compressed responses (e.g. gzip, brotli)
Web not working with compressed responses (e.g. gzip, brotli)
Jan 19, 2024
馃悰 Bug Report
Looks like any image url that returns an compressed response from the server does not work. The error in the console is:
I understand that web-Support is listed as limited due to no caching, but I guess it should at least load the image with that "limited support", as
Image.network(...)
also does it just fine. Compressing server responses should be a common thing, and often times cannot even be switched off on server platforms.My best guess: Maybe that the Content-Length Header is used to create some kind of buffer for the image but this header only provides the number of bytes of the body after compressing it. Using this number anyway would result in a buffer that is too small, which would explain the message. I did not figure out a way to debug this any further yet, so this really is just a guess, but maybe it helps.
I encountered this error for gzip and brotli (br) compression. Disabling the compression makes it work.
Expected behavior
Expecting to see an image but getting an error widget instead.
Reproduction steps
Load any image that is delivered by the server using some kind of compression (e.g. gzip or brotli/br).
Configuration
Version: 3.3.1
Platform:
The text was updated successfully, but these errors were encountered: