Would you mind trying firebase emulators:start --only functions,hosting --debug and post the longer debug log? There may be some interesting things in the fuller log.

@jasdevsidhu12 in addition to the logs @yuchenshi requested can you show your firebase.json? Generally when using a framework like React or Vue you don't use localhost:5000 as your dev server because that will serve the files listed in your hosting public folder which is normally something like app/dist or another folder of production built files. Instead you should use the local web server built in to Next.js

Hi @yuchenshi thanks for replying quick :)
Here's the log https://github.com/jasdevsidhu12/test-next/blob/firebase-issue/firebase-debug.log . I couldn't find anything interesting :(

Hi @samtstern here's my firebase.json file https://github.com/jasdevsidhu12/test-next/blob/firebase-issue/firebase.json
about localhost:5000 I think firebase emulators:start --only functions,hosting assigns it. I'm not sure whether I can change it.
If I use NextJS Dev server which normally host is localhost:3000 it doesn't have any issues but I would love to test the whole application before deploying it to firebase.

@jasdevsidhu12 if you look at your firebase.json you'll see this:

{
  "hosting": {
    "public": "server/dist",

This means Firebase Hosting (in prod and when emulated) will serve the contents of server/dist. This is generally the output of npm run build. The hosting emulator does not proxy the contents of the Next.js dev server.

So while developing you should continue to use the NextJS dev server. If you want to test before deploying first build your website for production so it's in server/dist and then check out the hosting emulator.

There's some discussion of this issue here:
#594 (comment)

You may be able to point the Next.js dev server at server/dist in which case everything should just work. For now I am closing this as intended behavior, let me know if I missed something!

Hi @samtstern,
I'm using an express-server to serve/render those NextJS files and its in my repository the server file..

My express-server is using the firebase cloud-function/hosting name helloWorld [line 20] to "run on". The cloud-function name is also stated in my firebase.json file [line 7].

So when I run my express-server/cloud-functions/hosting locally using firebase emulators:start --only functions,hosting command it produces the following error (image below).

However, if I run my express-server only without using cloud-functions/hosting it works without any issues(images below) .
(screenshot from my server file.)

Results (pure express-server)

Moreover the same express-server/cloud-functions/hosting is what I deployed to my firebase fir-nextjs-note-app application and it works over there (from my 1st comment). So in a nutshell, the express-server/cloud-functions/hosting breaks(cannot render the html file) when I run firebase emulators:start --only functions,hosting locally. Can you help me out and is this issue still close?
I appologise I should have given more background on this issue.

Can you show the full request and response (url, headers, data, etc) from the test request you circled in the Chrome console?

Also it looks like you're trying to send /test to the helloWorld function but your firebase.json does not have the configuration for that:
https://firebase.google.com/docs/hosting/functions

You need to add something like this:

"hosting": {
  // ...

  // Add the "rewrites" attribute within "hosting"
  "rewrites": [ {
    "source": "/test",
    "function": "helloWorld"
  } ]
}

so when I hit request /test the following are the headers. I'm not passing any query.

and in cmd log

Still cant find anything unusual

Also on the URL rewrites I want all request to hit the helloWorld express-server/cloud-functions, hence "source": "**"

Hi folks. I was able to replicate this issue and I think the root cause is similar to #3052.

When the hosting emulator is streaming a response, there's a case where the caller may be expecting compressed content and the proxy is decompressing the content and streaming that back as a response. This causes issues where it can't decompress the content (because it's not compressed) and the content looks truncated (because it's coming back with a content-length of the compressed response rather than the raw response.

I'm working on a PR that should address this issue (I was able to verify that the fix worked in this case too, if I remember yesterday correctly). I'm making sure to add some tests to make sure it's behaving as expected, too.

Thanks for your patience.

@bkendall thanks for watching this thread!