4

The server and client in different time zone. The difference in 6 hours. The server sets a cookie for 1 hour but the client correctly receives it and keeps an hour, although the client is currently 5 hours ago. How client correctly sets the cookie exactly on the hour? Could be the browser looks at the header "Date"? if so, what if the server will be behind another proxy server, which will set own "Date" header?

Must provide proof with a reference to rfc or something where.

Logioniz
  • 891
  • 6
  • 15

2 Answers2

4

There are 2 ways to specify a maximum age for the cookie:

Max-Age is relative to the time of setting.. So Texpiration = Tsetting + Max-Age

Otherwise, the Expires attribute sets a date / time value including a timezone: https://www.rfc-editor.org/rfc/rfc6265#section-5.1.1

Example from the RFC itself:

Expires=Wed, 09 Jun 2021 10:18:14 GMT

There are many standards (old and new) that favor GMT (UTC) as a date / time format:

From RFC2616 we got the so called HTTP format:

All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated Universal Time).

The Expires attribute should also set the time in HTTP format:

e.g. Set-Cookie: reg_fb_gate=deleted; Expires=Thu, 01-Jan-1970 00:00:01 GMT; Path=/; Domain=.example.com; HttpOnly (from Wikipedia)

Community
  • 1
  • 1
Sandman
  • 2,577
  • 2
  • 21
  • 32
2

The timezone actually shouldn't matter, as HTTP dates are supposed to be in UTC (historically GMT) anyway (cf. RFC7231, sec. 7.1.1.1):

An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC). The first two formats indicate UTC by the three-letter abbreviation for Greenwich Mean Time, "GMT", a predecessor of the UTC name; values in the asctime format are assumed to be in UTC.

Then, the Date header of the server should be authoritative as the Set-Cookieheader knows no date itself (cf RFC6265, sec. 4.1.1). Your assumption that the next proxy will tack its own Date header is a bit off. This should only ever happen if the originating server itself has not set one (cf RFC7231, sec. 7.1.1.2):

An origin server MUST NOT send a Date header field if it does not have a clock capable of providing a reasonable approximation of the current instance in Coordinated Universal Time. An origin server MAY send a Date header field if the response is in the 1xx (Informational) or 5xx (Server Error) class of status codes. An origin server MUST send a Date header field in all other cases.

A recipient with a clock that receives a response message without a Date header field MUST record the time it was received and append a corresponding Date header field to the message's header section if it is cached or forwarded downstream.

Community
  • 1
  • 1
DaSourcerer
  • 6,288
  • 5
  • 32
  • 55