When the 'no-cache' Response Caching Header set, 'max-age' still required.

[lc6464]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

In ASP.NET Core Web API (MVC)，I received An unhandled exception occurred while processing the request.

InvalidOperationException: If the 'NoStore' property is not set to true, 'Duration' property must be specified.
Microsoft.AspNetCore.Mvc.Filters.ResponseCacheFilterExecutor.Execute(FilterContext context)

I set the cacheProfile.Location ResponseCacheLocation.None, the Cache-Control response header should have been set to no-cache, but it threw an exception. If I set Duration = 0, the value of the response header will become no-cache,max-age=0, which doesn't seem reasonable.

Expected Behavior

When I set Location to None, it should not throw an exception, and set the value of the response header to no-cache without max-age.

Steps To Reproduce

1. Clone https://github.com/lc6464/api.lcwebsite.cn.git
2. Remove Duration = 0, in Program.cs:39
3. Changed Private1m to NoCache in Controllers\GetIPController.cs:18.
4. Build
5. Visit http://localhost:5000/GetIP

Exceptions (if any)

An unhandled exception occurred while processing the request.
InvalidOperationException: If the 'NoStore' property is not set to true, 'Duration' property must be specified.
Microsoft.AspNetCore.Mvc.Filters.ResponseCacheFilterExecutor.Execute(FilterContext context)

.NET Version

6.0.302

Anything else?

ASP.NET Core 6.0
Visual Studio 2022 17.2.6
dotnet --info:

.NET SDK (反映任何 global.json):
 Version:   6.0.302
 Commit:    c857713418

运行时环境:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.302\

global.json file:
  Not found

Host:
  Version:      6.0.7
  Architecture: x64
  Commit:       0ec02c8c96

Thanks for contacting us.
We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

Thanks for contacting us.
We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.