on master help sign in
wai-app-static: argue by rfc when doing cache decisions

The RFC has a clear description of what MUST be done with If-Modified-Since if an ETag is sent by the client. Fortunately, we conformed to that description.

commit2be3727784444359607664b4ad518241b8839d70 authorPhilip Patsch <philip.patsch@tweag.io> dateFri 24 Jan 2020, 12:29 (7 years ago) parent73f7922
1 file changed+7−5
wai-app-static/Network/Wai/Application/Static.hs+7−5
wai-app-static/Network/Wai/Application/Static.hs+7−5
@@ -164,11 +164,13 @@ serveFile StaticSettings {..} req file
164164 -- Didn't match, but we have a hash value. Send the file contents
165165 -- with an ETag header.
166166 --
167− -- Note: It would be arguably better to next check
168− -- if-modified-since and return a 304 if that indicates a match as
169− -- well. However, the circumstances under which such a situation
170− -- could arise would be very anomalous, and should likely warrant a
171− -- new file being sent anyway.
167+ -- RFC7232 (HTTP 1.1):
168+ -- > A recipient MUST ignore If-Modified-Since if the request contains an
169+ -- > If-None-Match header field; the condition in If-None-Match is
170+ -- > considered to be a more accurate replacement for the condition in
171+ -- > If-Modified-Since, and the two are only combined for the sake of
172+ -- > interoperating with older intermediaries that might not implement
173+ -- > If-None-Match.
172174 (Just hash, _) -> respond [("ETag", hash)]
173175
174176 -- No hash value available, fall back to last modified support.