Better tag RESTBase as well.

It looks like this is the setting we're after: https://github.com/wikimedia/operations-puppet/blob/443c9cd7d10398d457a89341dde225df308bc120/modules/restbase/templates/config.yaml.erb#L76

The must-revalidate directive is there mainly to prevent vandalism, but also to ensure that the client always has the freshest response in cache. I believe this ticket is in the context of offline usage. While the RFC clearly states that the client must check with the server, it can also detect that it is offline and hence it has real-world obstacles from fulfilling the contract. Removing the directive altogether in order to accommodate such an edge case doesn't seem prudent to me, TBH.

While the RFC clearly states that the client must check with the server, it can also detect that it is offline and hence it has real-world obstacles from fulfilling the contract.

No, the RFC states that 504 MUST be returned in this case: https://tools.ietf.org/html/rfc7234#section-5.2.2.1

In T156829#2988623, @Pchelolo wrote:

While the RFC clearly states that the client must check with the server, it can also detect that it is offline and hence it has real-world obstacles from fulfilling the contract.

No, the RFC states that 504 MUST be returned in this case: https://tools.ietf.org/html/rfc7234#section-5.2.2.1

That presumes the request has reached the cache in the first place, which is not true for offline mode, While cache here is rather open to interpretation and can include the client's cache, I still think that offline mode is such a special case that it doesn't warrant removing the directive.

That presumes the request has reached the cache in the first place, which is not true for offline mode, While cache here is rather open to interpretation and can include the client's cache, I still think that offline mode is such a special case that it doesn't warrant removing the directive.

I'm not really sure how the client cache is different from any other cache

The RFC says: https://tools.ietf.org/html/rfc7234#section-4.2.4

A cache MUST NOT send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path)

So basically for normal case (connected) must-revalidate and absence of it should have no difference at all.

In T156829#2988635, @Pchelolo wrote:

A cache MUST NOT send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path)

So basically for normal case (connected) must-revalidate and absence of it should have no difference at all.

IMO this is right, and we shouldn't need to mess with the headers coming from the server side.

(We will have to mess with our OkHttp client cache, which is implemented to comply with RFC 7234, to allow it to conditionally give us must-revalidate content when offline, but that's a separate matter.)

(Edit: for technical correctness)

Making this change doesn't seem to be necessary for the Android client or desirable in the general case. Anyone object to declining?

I'm afraid I can't champion this effort but I stand by the principal that clients should be able to respect the header directives issued by the server. As far as I know, the current implementation makes this impossible for offline-friendly applications.

From a practical perspective, I think the biggest question is how common clients behave these days when must-revalidate is omitted, and the client cache timeout expires. My memory on this is rather foggy, but I *think* in the dark ages behavior in that area was inconsistent, with early IE versions not re-validating even when they were online. If we can verify that all browsers we care about do the right thing (check as if must-revalidate was set when connected), then dropping must-revalidate in the headers would be harmless.