test stale-while-revalidate and stale-if-error

[jameysharp]

trafficstars

Fixes #17.

I'm not super confident about whether these are the right tests for these features but it seemed like one of the more straightforward cache extensions to test. Also, I personally want to be able to use these features in my web development work.

It looks to me like Firefox and Chrome implement stale-while-revalidate, but none of the proxies do, and nothing I can test implements stale-if-error, which seems like a shame.

[jameysharp]

You were right that I needed to change to max-age=1 and always using pause_after. Otherwise I think Varnish didn't do stale-while-revalidate, and also that gets several caches to do stale-if-error that didn't otherwise.

And, ohhh. I assumed that a cache which implements stale-while-revalidate would return the cached response, then forward the request which triggered revalidation as-is—but I guess there's nothing requiring it to work that way? The cache could generate its own request, ignoring any headers provided by the client, huh?

The caches I'm testing, if they implement this at all, seem to work like I expected. Chrome, Firefox, and Varnish forward the client's request, including the Req-Num header. For apache, nginx, squid, and trafficserver, they're clearly returning the result of revalidation on the second request, as if stale-while-revalidate were not present.

I don't quite see how to use the current test infrastructure to test this without assuming that the client's request will get forwarded to the server. Can you suggest how this test could be written instead?

[mnot]

Yep - as per the spec:

When generating a conditional request for validation, a cache starts with either a request it is attempting to satisfy, or — if it is initiating the request independently — it synthesises a request using a stored response by copying the method, request-target, and request header fields identified by the Vary header field Section 4.1.

It then updates that request with one or more precondition header fields. These contain validator metadata sourced from stored response(s) that have the same cache key.

It seems like we need a new expected_type that will check that Server-Request-Count has incremented (because a new response was generated by the server side), but Req-Num was either not present in its request, or is one of the previous request numbers generated by the client (indicating that the request that the server saw was not the one just sent).

This is just thinking out loud -- does that make sense?

[mnot]

In the meantime, how request numbers are calculated have changed, so I think this might now work, with the suggested changes above. Do you want to have a go at that? If not, no worries, I'll just merge and have a try.

Thanks again!

[mnot]

Thanks and sorry for the extreme delay; I went ahead and added these in bea115b4.