Alkir and also reduces the load on the server
I don't think this is necessarily true. You do save time transmitting the response if you send a 304 response along with the Last-Modified header, but depending how the feature is written in the backend, you might not end up saving a lot of load on the server, if any. In the case of Flarum, you'd still need to retrieve all posts from the page of the discussion asked in order to find the last modified time. If you do this by generating the page and inspecting the payload data via a middleware, this will still have taken the same time + the processing needed for the middleware. This could be sped up to some extend by having a dedicated middleware calculating the modified time directly from the database before relaying to the normal controller, but this ends up duplicating some code and potentially slowing down actual, fresh requests because now we are querying the database again to fetch the actual API data.
The only win I see is with caching. If the (static) cached pages have already been generated, then it's not a lot of work to store the associated modified time and return it as part of the cached payload. I believe such an extension is in the work as a premium extension, not sure if the modified header is part of the features.
So the use case here was accelerating the crawling by search engine ? Do you notice a significant performance issue with default Flarum ? Have you identified which part of the process is the bottleneck ? Are you sure the modified header is an actual solution to that problem ?
I love to discuss potential Flarum features but I have a feeling we are subject to the "XY problem" here (and also in some of your previous discussions). Either this discussion is about extending Flarum and then we should get technical with what you attempted and where you are stuck implementing it, or if you're looking to a solution for a problem you encounter we need more information about that problem 😉
