On 2/25/18, Florian Balmer <florian.bal...@gmail.com> wrote: > As far as I remember, I've come across the recommendation to combine > ETags and Last-Modified headers, so the client could pick > If-None-Match or If-Modified-Since to validate its cached content. > > And, it's already there, and works like a charm!
Yes. But because of the issue described previously, I wonder if I shouldn't drop support for If-Modified-Since? Do we know that all clients that support both If-None-Match and If-Modified-Since will always choose If-None-Match if it is available from the server? In that case, it might be acceptable to leave in support for If-Modified-Since. But if the presence of If-Modified-Since might cause some clients to use it in place of If-None-Match, then we should take it out. Does anybody know? Is there any reader on this list who as parsed the text of the relevant RFCs and knows the answer? Can you brief me, and prehaps give a link to the appropriate standard? At the very least, I should probably fix Fossil so that never sends a Last-Modified reply header (used by If-Modified-Since) unless there is also an ETag header. That would prevent incorrect answers on any client ETag capable and which always prioritizes ETag over Last-Modified. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
