don't cache failures!

[zooko]

I just had a transient failure to load a file (due to #2116), and then every subsequent attempt to load that file got an "HTTP/1.1 304 Not Modified". Inspecting the headers shows me that my browser is sending:

If-None-Match:	wjdbbu5qjheyfxmwgy5onsx6qy

and the Tahoe-LAFS gateway sent back:

Etag:	wjdbbu5qjheyfxmwgy5onsx6qy-

This is a bug! Only successful file fetches should get an Etag. Error/failure notices like this one should not:

NoSharesError: no shares could be found. Zero shares usually indicates a corrupt URI, or that no servers were connected, but it might also indicate severe corruption. You should perform a filecheck on this object to learn more.

The full error message is:
no shares (need 1). Last failure: None

[zooko]

To fix this ticket, you should first extend the unit tests so that they exercise the case of making a request of the WUI, which request results in a NoSharesError, and then your test should give WUI a red flag if the WUI sets the Etag on that. Or, well, I guess it should give it a red flag if it sets the same Etag value on a failure message result as it does on a successful delivery of the file. (Because it would be legit for the WUI to set an Etag on the failure message result as long as it sets that Etag iff the exactly same failure message result is the answer.)

Here is a previous patch by Brian that extended these tests to cover a similar situation. You could model your patch that extends the tests on this patch:

[5d404db89/trunk]

[daira]

I agree, this is a violation of the HTTP spec (I can't see where it is stated explicitly that ETags shouldn't be sent for possibly-transient error responses, but it is implied by "an origin server must avoid reusing a specific strong entity tag value for two different entities" in ​https://tools.ietf.org/html/rfc2616#section-13.3.3).