7

why the fuck those images wouldn't load? they come corrupt from K8S, but they are fine if I run the container locally, like... wtf? is Ingress NGINX doing something to them or did I configure something wrong?!

Comments
  • 5
    Needs more sacrifices.
    *nod*
  • 2
    Exec into ingress nodes and curl them via service domain and via localhost [nginx]. And you'll see
  • 1
    You could also try figure out exactly how they're I'll formed and take it from there
  • 3
    @ScriptCoded it's the bit after 89 50 4e 47 that's different, for some reason :/
  • 5
    @catholic-emacs that my friend is a newline conversion (\r\n the network standard turned \n). Do you perhaps work on Windows? If so check your git auto conversion crap in check-in.
  • 4
    @hjk101 I use Arch, btw

    (I do use Arch)
  • 4
    @catholic-emacs ok check the images on disk in cloud. If that is fine check where newline replacement is going on in the serving pipeline. If not see how this got saved (ftp for example can do this).

    This shit is not standard.
  • 5
    Specify content-type as image/png. If it's text/plain, your webserver/http proxy *may* decide to replace \n with \r\n if it sees Windows in the User-Agent header.
  • 1
    @netikras I was able to exec into the Ingress pod and perform a cURL to localhost and the Header says its a image/png. Doing a cURL to a service domain name doesn't work for me (<service>.<namespace>.cluster.local isn't doing it for me)
  • 0
    I pulled my container from Gitlab, ran it and to my surprise I'm receiving the same corrupt file back 🤔🤔🤔🤔🤔🤔🤔
  • 1
    @catholic-emacs and the contents? Is it \0a\0d via localhost?

    If service name resolution doesn't work (why wouldn't it tho....?), try with a pod's IP.

    See if the response content is the same. And compare the resp headers.
  • 2
    @catholic-emacs does curl and the browser fetch the same identical response body? Might be worth comparing
  • 0
    Why would Gitlab CI corrupt my dear PNGs 😢😢😢

    Removing intermediate container fcdf21fc9669
    ---> e029e5717006
    Step 5/6 : COPY static/ ./
    ---> fcb8c73cdba6
    Step 6/6 : RUN sha256sum -c files.txt
    ---> Running in 10c05798db5b
    browserconfig.xml: OK
    favicon-114.png: FAILED
    favicon-120.png: FAILED
    favicon-144.png: FAILED
    favicon-150.png: FAILED
    favicon-152.png: FAILED
    favicon-160.png: FAILED
    favicon-16.png: FAILED
    favicon-180.png: FAILED
    favicon-192.png: FAILED
    favicon-310.png: FAILED
    favicon-32.png: FAILED
    favicon-57.png: FAILED
    favicon-60.png: FAILED
    favicon-64.png: FAILED
    favicon-70.png: FAILED
    favicon-72.png: FAILED
    favicon-76.png: FAILED
    favicon-96.png: FAILED
    favicon.ico: OK
    robots.txt: OK
    site.webmanifest: OK
    sha256sum: WARNING: 18 computed checksums did NOT match
  • 0
    there are Windows servers running the CI/CD on Gitlab, makes me wonder if this is the culprit
  • 1
    so I ended activating Git LFS on my repo and that prevented data corruption. Probably Git is doing something that it should because the files on the repo were already corrupt upon checking
Add Comment