Repository: next.js
Issue: Accept-Encoding header is not respected when using `NextResponse.next` with a request option
Labels: bug,Runtime

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.4.0: Mon Mar  6 21:00:41 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T8103
    Binaries:
      Node: 20.5.0
      npm: 9.8.1
      Yarn: N/A
      pnpm: N/A
    Relevant Packages:
      next: 13.4.19
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.3
    Next.js Config:
      output: N/A
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

Middleware / Edge (API routes, runtime)

### Link to the code that reproduces this issue or a replay of the bug

https://github.com/beckerei/next-middleware-encoding-bug

### To Reproduce

1. `npm run dev` or `npm run build && npm run start`
2. Do a request against the running next server, for simplicity you can use curl as stated below. I used Insomnia to do the same request.

```
curl --request GET \
  --url http://localhost:3000/ \
  --header 'x-foo-bar: baz'
```

You need a middleware in the project that does the following:

```ts
import { NextResponse } from 'next/server';
import type { NextMiddleware } from 'next/server';

export const middleware: NextMiddleware = (request, event) => {
  console.log('requestHeader', request.headers);

  return NextResponse.next({ request }); // ignores accept-encoding header

  return NextResponse.next(); // respects accept-encoding header
};
```

### Describe the Bug

The `accept-encoding` header describes what kind of encoding the requester understands.
We can leave it out, or specify something other than `gzip` e.g. brotli or deflate.

The request inside the middleware does not contain the `accept-encoding` header that was requested but looks different. I added an additional header (`x-foo-bar`) to verify that this header is still present.

You can see `x-foo-bar=baz` is as expected but `accept-encoding=gzip, deflate` does not look like our request header.

```js
Headers {
    [Symbol(headers list)]: HeadersList {
        [Symbol(headers map sorted)]: [
            ['accept', '*/*'],
            ['accept-encoding', 'gzip, deflate'],
            ['accept-language', '*'],
            ['cache-control', ''],
            ['connection', 'keep-alive'],
            ['host', 'localhost:3000'],
            ['sec-fetch-mode', 'cors'],
            ['user-agent', 'insomnia/2023.2.2'],
            ['x-foo-bar', 'baz'],
            ['x-invoke-output', ''],
            ['x-invoke-path', ''],
            ['x-invoke-query', ''],
            ['x-middleware-invoke', '1']
        ]
    },
}
```

As a result, all pages are gzipped and contain the `Encoding=gzip` response header.

### Expected Behavior

The `accept-encoding` header should be respected, if none is set no compression should be applied. This does work without a middleware, or when you don't pass a/the original request to `NextResponse.next`.

**What is our use case?**
We leverage server-side and edge-side includes across our FE applications to include HTML fragments. In order for our CDN or nginx to translate these tags the HTML must not be compressed.
For now, we drop the accept-encoding header from the requests and do compression after these tags are included.
After `13.4.13` this stopped working, and all responses are zipped.


### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

next start / Docker