Sinatra: expires method overwriting Cache-Control max-age

[iguchi1124]

I have a question about expires method.
I am reading https://tools.ietf.org/html/rfc7234#section-5.3,

If a response includes a Cache-Control field with the max-age
directive (Section 5.2.2.8), a recipient MUST ignore the Expires
field. Likewise, if a response includes the s-maxage directive
(Section 5.2.2.9), a shared cache recipient MUST ignore the Expires
field. In both these cases, the value in Expires is only intended
for recipients that have not yet implemented the Cache-Control field.

Sinatra's implementation of expires method is overwrite Cache-Control header max-age forcibly. for that why, Expires header is ignored by client.

I suggest to stop overwriting Cache-Control header max-age at next patch version.

And, I think the expires method name is very ambiguous(overwriting Cache-Control values, not only Expires). At next major version, I propose to rename method or re-design this method.

What do you think?

[iguchi1124]

I'll work this issue.

[namusyaka]

@iguchi1124 No. You should work on this after the issue becomes more clearer.
At first, we need to discuss the issue.

[iguchi1124]

@namusyaka Ah, it meant that I want to work for next patch version things, to stop overwriting Cache-Control header max-age forcibly. Isn't it bugs?

[namusyaka]

The behavior has existed for nine years, and then it looks like intentional. Even if the behavior is not valid, we cannot fix it as patch-level release. Maybe minor version release. Thoughts?

[iguchi1124]

I checked RFC2616 which is referenced by implementer probably,

https://tools.ietf.org/html/rfc2616#section-14.21

Note: if a response includes a Cache-Control field with the max-
age directive (see section 14.9.3), that directive overrides the
Expires field.

I think forcibly overwriting is not intentional.

For example, Expires specified time and max-age duration are able to indicates not equal expires time by network latency.

[namusyaka]

What would you do if you are to tackle this problem?
Could you show me the simple patch?

[namusyaka]

This issue has two problems.
I think you know about those. Could you separate your issues?

[iguchi1124]

first of all, I created issue https://github.com/sinatra/sinatra/issues/1424

[dentarg]

The behavior has existed for nine years, and then it looks like intentional. Even if the behavior is not valid, we cannot fix it as patch-level release. Maybe minor version release. Thoughts?

@namusyaka It is good that you are raising the concerns of breaking existing behaviour. But Sinatra states that it follows Semantic Versioning, which means that people does not expect any breaking changes, even in minor version. I think that is important to consider for all changes made to Sinatra.

My suggestion is that you shouldn't be afraid of releasing major versions with breaking changes more often. And document clearly what is breaking. Then people can deal with it.

If we go that way, people may request support for multiple major versions. My suggestion in that area is that we don't, the reality is that there isn't that many people working in Sinatra to do that. Of course that could be reconsidered if more people join in and contribute to the project.

[jkowens]

From what I understand it is considered good practice to have the Expires header and max-age directive contain matching values. If any change is necessary, I think that the cache_control method should set the Expires header with a matching time value. That way both cache_control and expires will set the Cache-Control and Expires headers with matching values.