Firebase storage image not displaying in nextjs application

Question

I am using the Next.js template from Vercel and just trying to replace the logo image at the bottom with one that is stored in Firebase storage. I have configured the next.config.js and it does not throw an error but the image is not displayed. It is only showing the image missing placeholder with alt text. This is my next.config.js

/**

* @type {import('next').NextConfig}

*/
const nextConfig = {

  images: {
  
  domains: ['firebasestorage.googleapis.com'],
  
  },
  
};
  
  
module.exports = nextConfig;

I can also access the image in my browser.

EDIT 14/08/21**

When I replace the nextjs image tag with a standard html tag the image does load so it seems to be some issue with next.

Answer 1

Yes I got the same issue and sloved by chagning image tag from NextJs tag to normal html tag. this will work, yes you will get an eslint warning but you don't have other opitons Hope this might help

Answer 2

I solved it using the 'unoptimized' property in nextjs

                <Image
                    src={item?.categoryImageUrl ?? placeholderImage}
                    alt={item?.categoryName || t("text-card-thumbnail")}
                    width={imageSize}
                    height={imageSize}
                    // quality={100}
                    unoptimized
                    className={`object-cover bg-gray-300 ${
                        variant === "rounded"
                            ? "rounded-md"
                            : "rounded-full"
                    }`}
                />

Read more about this at nextjs unoptimized

Answer 3

The IANA method registry currently lists draft-ietf-httpbis-semantics#section-9.3.3 as the authoritative reference for POST:

Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [CACHING]) and a Content-Location header field that has the same value as the POST's target URI (Section 8.7). A cached POST response can be reused to satisfy a later GET or HEAD request, but not a POST request, since POST is required to be written through to the origin server, because it is unsafe; see Section 4 of [CACHING].

Using the Content-Location header in this way is how we indicate that the payload of the response is a representation of the target resource, as opposed to being any arbitrary status of the action.

---

What are some use cases that this would make sense?

Any time POST is being used to modify the target resource

GET /the-car

200 OK
Content-Type: application/json

{ "color" : "red" }

POST /the-car
Content-Type: text/plain

Bob, the car should be blue, can you fix that please?

200 OK
Content-Type: application/json
Content-Location: /the-car

{ "color" : "blue" }