Revalidated requests does not update the stored cache for that request #31
Description
Hi,
I've been toying with this transport middleware, and I've noticed something curious.
When a request gets revalidated, it passes through https://github.com/bartventer/httpcache/blob/master/internal/validationresponsehandler.go#L80-L86 . This updates the headers being sent back to through the chain, but it does not seem to update the cache based on the newly received headers.
Example flow:
Request 1 (MISS)
No cache exists, so a request gets sent
Server responds with 200 and an `Expires` header with a value N time in the future
Request 2 (HIT)
Cache exists, and is fresh, no request gets sent
Wait N time
Request 3 (REVALIDATED)
Cache exists, but has expired, so revalidation is needed
Server responds with a 304 and an `Expires` header with a value N time in the future
Request 4 (REVALIDATED)
Cache exists, but still shows expired, so another revalidation request is made
Server responds with a 304 and an `Expires` header with a value N time in the future
The expected flow is that after request 3, the server indicates a new expiry time, so the cache can be considered fresh again as per 4.3.4:
For each stored response identified, the cache MUST update its header fields with the header
fields provided in the 304 (Not Modified) response, as per Section 3.2.
making a flow as follows:
Request 1 (MISS)
No cache exists, so a request gets sent
Server responds with an `Expires` header with a value N time in the future
Request 2 (HIT)
Cache exists, and is fresh, no request gets sent
Wait N time
Request 3 (REVALIDATED)
Cache exists, but has expired, so revalidation is needed
Server responds with an `Expires` header with a value N time in the future
Request 4 (HIT)
Cache exists, and is fresh, no request gets sent