fetch-with-init-then-request sets Content-Type request header for GET

[sideshowbarker]

https://github.com/mdn/fetch-examples/blob/7a20c41cb1d65c5e8ae9eae3270caa2dadadf12e/fetch-with-init-then-request/index.html#L25-L36 That example is setting a Content-Type request header for a GET request, which serves no real purpose since the request has no request body/payload.

I guess a simple fix would be to change the request header to an Accept header. But it seems like that wouldn’t be serving much real purpose either, since the request for flowers.jpg will without any Accept request header needed return that JPEG file as expected anyway.

A more real-world example would be a POST request with a JSON request payload/body and a Content-Type: application/json request header. But I don’t know if/how that would fit with how the set of examples here are served.

Regardless, I’m happy to help work on putting together another example that illustrates the same thing this one’s intended to illustrate.

But note also that whatever changes we make here, we will also need to update the example code at https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch#Example, which repeats the code from here.

[chrisdavidmills]

Hi @sideshowbarker! I'm sorry it has taken me, like, 4 months to reply to this. It just slipped out of view at the bottom of my inbox. ;-(

I'd love it if you could throw together an improved example for this. I think the post example with some simple JSON would be the best route to take. I can update the necessary MDN pages.

[sideshowbarker]

Thanks @chrisdavidmills — is there a maintained endpoint I can POST some JSON to as part of the demo (and get a useful response back from)?

[chrisdavidmills]

@sideshowbarker Oh gawd, I don't know. I'll ask around.

[chrisdavidmills]

Would http://www.jsontest.com/ be any use?

[sideshowbarker]

Would http://www.jsontest.com/ be any use?

Yes — thanks much, will use that

[chrisdavidmills]

This one also looks pretty useful: http://httpbin.org/

[schalkneethling]

We are in the process of merging some of our smaller repositories into our larger, more well-maintained repositories. This repository is being moved to the dom-examples repository. While there were some updates to the file in question, the issue raised here still exists. Instead of closing this issue, I am going to transfer it to the dom-examples repo, where we can continue the conversation.

[bsmth]

Hey @sideshowbarker 👋🏻

I was looking at this one again recently and thinking of what might be interesting to show. My first thoughts are Authorization header, but we're running the example, so this would fail. What about doing something with caching?

const myImage = document.querySelector("img");

const reqHeaders = new Headers();

// reqHeaders.append("If-Modified-Since", "Fri, 1 Sep 2023 09:30:00 GMT");
// Accept is also not really necessary
// reqHeaders.append("Accept", "image/jpeg");
reqHeaders.set("Cache-Control", "max-age=604800");

const options = {
  headers: reqHeaders,
};

const req = new Request("flowers.jpg");

fetch(req, options)
  .then((response) => {
    if (!response.ok) {
      throw new Error(`HTTP error, status = ${response.status}`);
    }
    return response.blob();
  })
  .then((blob) => {
    const objectURL = URL.createObjectURL(blob);
    myImage.src = objectURL;
  })
  .catch((error) => {
    var p = document.createElement("p");
    p.appendChild(document.createTextNode(`Error: ${error.message}`));
    document.body.insertBefore(p, myImage);
  });

If-Modified-Since is good, but if we get a 304, then we have to do some other handling, which complicates it a little. What do you think?

[sideshowbarker]

Yeah, I think an example with a Cache-Control request header would be correct, and a big improvement

[bsmth]

Great, I've assigned myself, I can tag you for a review if you'd like to have a look