Reload goes back in time (http cache issue?)

[paulrouget]

STR:

• create a file test.html which contains just the letter a
• make it available via http (python3 -m http.server 8080)
• load it with servo
• change the content of test.html: a to b
• reload. see b
• reload. see a

Can't reproduce using a file:/// url

[jdm]

Hmm, I could reproduce this in a build based on ea4e3ae, but not in a build based on 37ab273. Now the cached entry is always used and I never see the updated content.

[jdm]

Nevermind, I can still reproduce it.

[jdm]

This looks like it happens because http_network_or_cache_fetch calls HttpCache::store after a revalidation request that returns a non-306 response. That means there are two cached responses, and then reloading calls HttpCache::refresh when the new revalidation request returns a 304. HttpCache::refresh just returns the first cached response, which is the older one in this case.

[jdm]

I think we should make HttpCache store overwrite any existing complete response so that we only ever have one complete response and an arbitrary number of incomplete responses for a particular cache entry.

[gterzian]

It's weird, on my Mac with python 3, it seems the server doesn't understand the if-modified-since request header, and responds with a 200 even though the resource has been modified...

see some printed logs.

Request headers: {"accept": "text/html, application/xhtml+xml, application/xml; q=0.9, */*; q=0.8", "accept-language": "en-US, en; q=0.5", "referer": "http://0.0.0.0:8080/test.html", "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:63.0) Servo/1.0 Firefox/63.0", "host": "0.0.0.0:8080", "accept-encoding": "gzip, deflate, br", "if-modified-since": "Tue, 08 Oct 2019 09:37:43 GMT"}
Forward response: {"server": "SimpleHTTP/0.6 Python/3.6.5", "date": "Tue, 08 Oct 2019 09:38:08 GMT", "content-type": "text/html", "content-length": "1", "last-modified": "Tue, 08 Oct 2019 09:38:04 GMT"} Some((200, "OK"))

So I can't seem to hit the refresh case.

Also note that this occurs because the python server by default sends a response containing a Last-Modified header(and also a Date).

I think a more appropriate fix could be to find the "right" stored resource to use in the refresh operation, by comparing the stored Last-Modified header with the one from the 304 response, as described at https://tools.ietf.org/html/rfc7232#section-2.2.2 in the second "or" paragraph(see also the use of the Date header in there).

[gterzian]

Also note that the "need to revalidate" is calculated based on the Last-Modified header of the cached resource, so one really needs to create, or modify, the test.html file right before starting the manual test, since otherwise the cached resource will remain valid for quite some time(10% of the time elapsed since the file was modified).

Just FYI in case someone starts to wonder why the test cannot be reproduced anymore...