I occasionally receive HTTP 500 errors on profile image URLs, e.g. this one:
These seem to persist essentially forever, so I’ve begun treating them like the 404s one gets for old, expired images after the user picks a new one. Nonetheless, it’d be great if you folks could improve the error code on these.
More concerning is the fact that, although the accompanying payload is your usual Sad Robot “Something is technically wrong” page, the Content-Type header is image/jpeg (or image/png, etc). This is simply wrong and you should fix it.
I believe this is made even worse by your use of the “X-Content-Type-Options: nosniff” extension. I’m not that familiar with this header, but its intent seems to be that the declared Content-Type must be taken at face value (even when it is clearly wrong). This means that well-behaved browsers must try to interpret the HTML payload as binary image data - which of course fails - so no one even sees the “Sad Robot” error page, they just see a broken image.