You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add Last-Modified header to http response or reply to HEAD requests #2797
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.
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.
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
@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.
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.
Activity
alexander-akait commentedon Oct 27, 2020
Nothing to do here, please open an issue in
webpack-dev-middlewarehttps://github.com/webpack/webpack-dev-middlewareNo, time based cache is the bad idea, I think you are looking for webpack/webpack-dev-middleware#738
I think you have a problems with tests, nginx should not answer 200 on non existing assets
watery commentedon Oct 27, 2020
@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-Taghint, 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 commentedon Feb 1, 2021
i need feed back all my report back thank you