1

Given:

const img = document.getElementById('img-id');

img.onerror = function() { … };

img.src = new_url;

Changing the source of the image element may result in my very specific use case in either:

  • A server status response 400 Bad Request, or
  • A server status response 200 OK with a Content-Type HTTP header that is not an image.

I would like to differentiate between both in the .onerror function.

I see the difference in the F12 console error of Chrome/Blink-based browsers and would like to capture this in a pure JavaScript conditional. Has the event related to .onerror any properties that may help to achieve this?

Note: This is for use in a progressive web application. By consequence, a solution that works with Chrome and Safari would suffice.

Serge Stroobandt
  • 28,495
  • 9
  • 107
  • 102
  • I don't think there is a way to tell the difference with JavaScript, that is reliable in all Browsers anyways. Why would it matter? If there's an error, there's an error. If you're getting the Element off of the page you would already know what you have in there, usually. I'm sure you can come up with a workaround. – StackSlave Apr 01 '21 at 23:53
  • Where is the image coming from to begin with? How is it being loaded into the DOM? https://www.php.net/pathinfo – StackSlave Apr 02 '21 at 00:30
  • So, you can just use the `XMLHttpRequest` to test for the path info via the link I supplied. – StackSlave Apr 02 '21 at 00:55
  • Sound sketchy. I'm out. – StackSlave Apr 02 '21 at 01:03
  • Your "400 Bad Request" response could still have a non null body, and even one that corresponds to a valid image. It's frequent for instance for image services like [imgur](https://i.stack.imgur.com/foobar.png) to return a valid placeholder image even when the request actually failed. In that case you won't have an error event at all. If the browser fails to decode it it's always because the resource was not a valid image, never because of a response status. – Kaiido Apr 02 '21 at 02:21
  • @Kaiido The server is actually a RESTful API server that will not return any image. I am only interested in knowing whether the server was happy —status `200 OK`— with my sent request. The RESTful request was sent through an `` request because that is one way of sending out a request without an `Origin` HTTP header. This is done to protect the privacy of the user as the `Origin` URL may refer to a medical condition. – Serge Stroobandt Apr 02 '21 at 08:54
  • Then why not ask that directly in your question? You are in a big fat X-Y Problem. And even if there was a way to do that through an (but there isn't, except if you have access to the server and you can make it return a valid image) there is probably better ways to do this than through an , for instance `fetch(url, { referrerPolicy: "no-referrer" })` would be the standard way of doing a request without referrer. – Kaiido Apr 02 '21 at 09:21
  • @Kaiido Your suggestion only affects the `Referer` [sic] HTTP header, which is the part of the URL after the fully qualified domain (FQD). [The FQD remains exposed in any fetch `Origin` header.](https://wiki.mozilla.org/Security/Origin#When_Origin_is_served_.28and_when_it_is_.22null.22.29) I am happy with the current `` solution; I am only curious to see whether it can be perfected. – Serge Stroobandt Apr 02 '21 at 10:09
  • Settting the request's `referrerPolicy: "no-referrer"` will not send any origin header. I'm not sure what you are talking about... – Kaiido Apr 02 '21 at 10:25
  • @Kaiido _It does._ I checked it with the `F12` Network tab in Vivaldi (a Blink-engine browser like Chromium/Chrome) and saving the requests in a `HAR` file. It is also what [this table](https://wiki.mozilla.org/Security/Origin#When_Origin_is_served_.28and_when_it_is_.22null.22.29) indicates. I also wished it were not like that … – Serge Stroobandt Apr 02 '21 at 10:41
  • Well certainly you did something wrong because per specs this header should be set to null. The table you link to is outdated and doesn't talk about fetch but only about `XHR`. – Kaiido Apr 02 '21 at 10:47
  • @Kaiido From the [Fetch Standard](https://fetch.spec.whatwg.org/#origin-header): "The `Origin` header is a version of the `Referer` [sic] header that does not reveal a path. It is used for all HTTP fetches whose request’s response tainting is "cors", […] " The API server happens to be [CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) and is a domain not controlled by myself. – Serge Stroobandt Apr 02 '21 at 11:14
  • @SergeStroobandt but for a cross-origin request you'd have to set the mode to "no-cors" which would not set the "Origin" header (however just like with img you'd not know the response status, but it still a lot less a hack. – Kaiido Apr 03 '21 at 00:18

1 Answers1

0

No you can't read the status code of a request made by an HTMLImageElement.

Your "400 Bad Request" response could still have a non null body, and even one that corresponds to a valid image.
It's frequent for instance for image services like imgur to return a valid placeholder image even when the request actually failed.

imgur's default 404 image fallback
https://i.stack.imgur.com/foobar.png

In that case you won't have an error event at all, for what the browser is concerned, it did receive a valid image and could decode it.

If the browser fires an error event, it's always because the resource was not a valid image, never because of a response status.

Kaiido
  • 123,334
  • 13
  • 219
  • 285