Add Last-Modified header to http response or reply to HEAD requests

[watery]

• Operating System: Docker with node:10.15.3-alpine image
• Node Version: 10.15.3
• NPM Version:
• webpack Version: from react-scripts @ 2.1.8
• webpack-dev-server Version: from react-scripts @ 2.1.8
• Browser: Any

• This is a bug
• This is a modification request

Code

// webpack.config.js

// additional code, remove if not needed.

Expected Behavior

Have the dev-server add a Last-Modified response header with a meaningful date-time, i.e. the last recompilation time; no need to be millisecond / second precise, it would be good enough if the recompile start event time or compilation complete event time is given, based on the easiest available one.

Actual Behavior

For Bugs; How can we reproduce the behavior?

For Features; What is the motivation and/or use-case for the feature?

I'm doing some experiments in a custom project that rely on HEAD requests and the Last-Modified response header: this is already provided by full-featured webservers, and would be nice to have here aswell, expecially in cases where the browser or page is closed and reopened between source code updates - which if I'm not mistaken, should detach the client code from the dev-server making the former lose the recompiled event that triggers a complete page reload.

I can't say whether the absence of the header in the response is due to it being not implemented or the fact that the dev-server replies with 404 to HEAD requests whereas web servers usually (well, I tested it with nginx) reply with 200.

[alexander-akait]

Nothing to do here, please open an issue in webpack-dev-middleware https://github.com/webpack/webpack-dev-middleware

Have the dev-server add a Last-Modified response header with a meaningful date-time, i.e. the last recompilation time; no need to be millisecond / second precise, it would be good enough if the recompile start event time or compilation complete event time is given, based on the easiest available one.

No, time based cache is the bad idea, I think you are looking for webpack/webpack-dev-middleware#738

I can't say whether the absence of the header in the response is due to it being not implemented or the fact that the dev-server replies with 404 to HEAD requests whereas web servers usually (well, I tested it with nginx) reply with 200.

I think you have a problems with tests, nginx should not answer 200 on non existing assets

[watery]

@evilebottnawi Thanks, it's easy to get lost among all webpack sub-projects.

Just to clarify: I'm not doing caching. In fact, I'm working on the opposite: detect a (React) app code change on the server that the client isn't seeing and continues to rely on the browser cached copy - this seems to happen mostly with small changes in the sources. And I'm trying to work around this without adding a dedicated service that returns the current webapp version.
This actually already works in production with a production build anda webserver. But not on our staging deployment, where we (well, react-scripts) server a debug build through a running dev-server.

Thanks for the E-Tag hint, I'll check that too.

About your last sentence, IMHO all of /, /home, /category/item, and so forth are all existing assets, and if I can GET them (and I definitely can even on dev-server) I think I should HEAD them too.

In fact I found this issue Should support HEAD request as well which appears to be closed just because the template was removed; I'll try to ask it again.

[pisal-rath]

• Operating System: Docker with node:10.15.3-alpine image

• Node Version: 10.15.3

• NPM Version:

• webpack Version: from react-scripts @ 2.1.8

• webpack-dev-server Version: from react-scripts @ 2.1.8

• Browser: Any

• This is a bug

• This is a modification request

Code

// webpack.config.js

// additional code, remove if not needed.

Expected Behavior

Have the dev-server add a Last-Modified response header with a meaningful date-time, i.e. the last recompilation time; no need to be millisecond / second precise, it would be good enough if the recompile start event time or compilation complete event time is given, based on the easiest available one.

Actual Behavior

For Bugs; How can we reproduce the behavior?

For Features; What is the motivation and/or use-case for the feature?

I'm doing some experiments in a custom project that rely on HEAD requests and the Last-Modified response header: this is already provided by full-featured webservers, and would be nice to have here aswell, expecially in cases where the browser or page is closed and reopened between source code updates - which if I'm not mistaken, should detach the client code from the dev-server making the former lose the recompiled event that triggers a complete page reload.

I can't say whether the absence of the header in the response is due to it being not implemented or the fact that the dev-server replies with 404 to HEAD requests whereas web servers usually (well, I tested it with nginx) reply with 200.

i need feed back all my report back thank you