3 ms·

They list "date" as being required by protocol. This is not true. The term used in the RFC is "should". It is a nice to have, for additional validation by pr

They list "date" as being required by protocol. This is not true. The term used in the RFC is "should". It is a nice to have, for additional validation by proxies. In haproxy, you can discard it with: http-response del-header Date

Rjevski 9y ago
Just curious, what would a proxy do with such a header?
- erulabs 9y ago
  I'd imagine its original design was so that the proxy could choose to honor the response date, rather than just use the current time - technically speaking the date header removes state from the proxy, as the proxy doesn't need to know what time it is to honor cache policies.
- LinuxBender 9y ago
  Proxies used to (and some still do) compare last-modified and date, if the date header is present. [0] They are not required to trust this header as accurate. For reference around and clarification around the Date header, the "should" comes from the loophole that nobody is required to have a time source. The previous RFC's made that harder to understand, as the loophole was in another section. [0] http://devel.squid-cache.org/rproxy/dateheader.html http://devel.squid-cache.org/rproxy/dateheader.html [1] https://tools.ietf.org/html/rfc7231#section-7.1.1.2 https://tools.ietf.org/html/rfc7231#section-7.1.1.2
  - rkeene2 9y ago
    I believe you have mis-interpreted Section 7.1.1.2 of RFC 7231, specifically it is identical to RFC 2616 Section 14.18 in that a Date header MUST be included except for 3 exceptions. They have listed the 3 exceptions first and also the wording that includes "SHOULD" which defines when the origin server should compute the date, but notwithstanding those notes it still notes that the Date header is mandatory for an origin server: "An origin server MUST send a Date header field in all other cases." (where other refers to the 3 exceptions -- HTTP 500-class errors; HTTP 100-class message-less responses; and no-clock systems)
    - LinuxBender 9y ago
      I understand what you are saying, but I am not required to have a time source, which makes the entire requirement optional.
      - rkeene2 9y ago
        A time source isn't required, a clock is. Further, if the origin server does not have a clock, any proxy (such as HAProxy) is still required to add the Date header if it has a clock, as if it were the origin server. In practice, there are very few functional systems without clocks.
rkeene2 9y ago
The term the RFC (RFC 2616, Section 14.18) uses is "MUST" with 3 exceptions (HTTP 100/101 responses, which are message-less; HTTP 500-class errors which are indications that the server is malfunctioning and during this malfunction it's inconvenient to generate a date; and finally HTTP servers without clocks), which are all referencing exceptional cases -- in general HTTP/1.1 responses MUST include a Date header from the Origin server, and proxies MUST add the Date header if the Origin server failed to do so (due to 1 or more of the 3 exceptions).
- LinuxBender 9y ago
  Except that, MUST becomes SHOULD because I am not required to have a time source. The exception negates the requirement.

Rjevski 9y ago

Just curious, what would a proxy do with such a header?

erulabs 9y ago
I'd imagine its original design was so that the proxy could choose to honor the response date, rather than just use the current time - technically speaking the date header removes state from the proxy, as the proxy doesn't need to know what time it is to honor cache policies.
LinuxBender 9y ago
Proxies used to (and some still do) compare last-modified and date, if the date header is present. [0] They are not required to trust this header as accurate. For reference around and clarification around the Date header, the "should" comes from the loophole that nobody is required to have a time source. The previous RFC's made that harder to understand, as the loophole was in another section. [0] http://devel.squid-cache.org/rproxy/dateheader.html http://devel.squid-cache.org/rproxy/dateheader.html [1] https://tools.ietf.org/html/rfc7231#section-7.1.1.2 https://tools.ietf.org/html/rfc7231#section-7.1.1.2
- rkeene2 9y ago
  I believe you have mis-interpreted Section 7.1.1.2 of RFC 7231, specifically it is identical to RFC 2616 Section 14.18 in that a Date header MUST be included except for 3 exceptions. They have listed the 3 exceptions first and also the wording that includes "SHOULD" which defines when the origin server should compute the date, but notwithstanding those notes it still notes that the Date header is mandatory for an origin server: "An origin server MUST send a Date header field in all other cases." (where other refers to the 3 exceptions -- HTTP 500-class errors; HTTP 100-class message-less responses; and no-clock systems)
  - LinuxBender 9y ago
    I understand what you are saying, but I am not required to have a time source, which makes the entire requirement optional.
    - rkeene2 9y ago
      A time source isn't required, a clock is. Further, if the origin server does not have a clock, any proxy (such as HAProxy) is still required to add the Date header if it has a clock, as if it were the origin server. In practice, there are very few functional systems without clocks.

rkeene2 9y ago

The term the RFC (RFC 2616, Section 14.18) uses is "MUST" with 3 exceptions (HTTP 100/101 responses, which are message-less; HTTP 500-class errors which are indications that the server is malfunctioning and during this malfunction it's inconvenient to generate a date; and finally HTTP servers without clocks), which are all referencing exceptional cases -- in general HTTP/1.1 responses MUST include a Date header from the Origin server, and proxies MUST add the Date header if the Origin server failed to do so (due to 1 or more of the 3 exceptions).

LinuxBender 9y ago
Except that, MUST becomes SHOULD because I am not required to have a time source. The exception negates the requirement.