Ensure Date header on expires_in

[arvida]

Background: Some webservers (thin and passenger for example) don't add a HTTP Date header to the response. This is not a problem for modern browsers but it can cause problems with other HTTP clients, for example Amazon's CloudFront expects a Date header when it gets a Cache-Control max-age value and .Net's HttpWebRequest's have some similar issue.
From what I understand the HTTP spec says that the client should use the Date header when calculating how a long a cached response is valid.

I can see that the Date header might not be Rails responsibility, but I think it would be good if #expires_in ensures that the client can use Cache-Control's max-age value by setting a Date header in the response. What you think about this?

[josevalim]

Leaving this open for discussion. As you said, setting the Date header is not Rails responsibility and I have never run into issues myself.

[arvida]

For me it comes down to that I want to be sure I get the expected behavior when calling expires_in.

[joliss]

As you said, setting the Date header is not Rails responsibility

Is it not? The thin people don't think it's their responsibility either: https://thin.lighthouseapp.com/projects/7212/tickets/89-date-header-missing

I wonder, is there any harm in always setting a Date header (with or without expires_in even)? RFC 2616 seems to pretty much say it should be there unconditionally: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18

[joliss]

Oh, and why I care about this obscure Date header thing? Because like @arvida I use CloudFront, which ignores max-age if I don't have the Date set.

For me this got triggered with a Sinatra app, but from this pull request it seems to me this might apply to Rails as well.

[arvida]

Great, thanks for merging this! 💃