I looked at Chrome’s web inspector while using the Mod UI over bluetooth and it looks like the browser does a
If-None-Match request for all images even if it is cached. The Mod responds with 304 (not modified) as expected, which does obviate the need to send the whole image again, but this still means an HTTP round trip for every image resource. Given the large number of individual resources, it would probably help performance quite a bit if the browser was able to use the cached response without checking for modification first.
This behavior is strange because the Mod UI responds to image requests with
Cache-Control: max-age=315360000, which should let browsers use the cached resource without checking (for ten years!). My guess is that this is because the responses have a bogus
Date: Thu, 01 Jan 1970 02:25:26 GMT which breaks the max-age cache logic.
Would it be possible to have the Mod set its clock from the UI client? Short of that, I think the correct behavior according to RFC 7231 section 18.104.22.168 is for the web server (Mod UI) to omit the
Date header completely:
An origin server MUST NOT send a Date header field if it does not
have a clock capable of providing a reasonable approximation of the
current instance in Coordinated Universal Time.
This should work correctly because a client receiving a response without a
Date is required to use the receive time as the