ServeDir lacks the Last-Modified response header

[photino]

Bug Report

Version

0.4.4

Platform

64-bit (Windows)

Crates

Description

The ServeDir lacks the Last-Modified response header even when it returns a 304 response.

[nathaniel-daniel]

To my understanding, it isn't strictly required to send a Last-Modified header for 304 responses: https://datatracker.ietf.org/doc/html/rfc9110#section-15.4.5

[photino]

It is also OK to return an ETag header. Without either Last-Modified or ETag, it is difficult for us to ensure that the content is unchanged.

[nathaniel-daniel]

It is also OK to return an ETag header. Without either Last-Modified or ETag, it is difficult for us to ensure that the content is unchanged.

Well, you would know it's unchanged because of the 304 response. An ETag header seems necessary for 304s, but a Last-Modified isn't. Also note that ServeDir doesn't use ETags at all. It is also explicitly stated that a Last-Modified header may be useful for responses without an ETag, but it isn't required.

I was just trying to note that the current behavior isn't technically wrong, but it might still be worthwhile to send a Last-Modified header for 304 responses.

[VlaDexa]

I was just trying to note that the current behavior isn't technically wrong

The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request

Not generating any of the representation headers conflicts a bit with the word MUST

Also MDN notes that the same RFC suggests generating both ETag and Last Modified when you can.

[nathaniel-daniel]

I was just trying to note that the current behavior isn't technically wrong

The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request

Not generating any of the representation headers conflicts a bit with the word MUST

Here's the full section:

The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false. In other words, there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored representation as if it were the content of a 200 (OK) response. The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request:
* Content-Location, Date, ETag, and Vary
* Cache-Control and Expires (see [CACHING])
Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, a sender SHOULD NOT generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding cache updates (e.g., Last-Modified might be useful if the response does not have an ETag field).

Note that Last-Modified is not a part of that header set. Also note the RFC explicitly gives an example of optionally sending a Last-Modified header for cache updates; the current behavior is technically correct, though sending that header might still be a good idea.

Also MDN notes that the same RFC suggests generating both ETag and Last Modified when you can.

This isn't really related to this issue, which is concerned with sending the Last-Modified header for 304 responses. I think you may want to see #324.