- From: Matthew Fenelon <matthew@huddle.com>
- Date: Tue, 6 Dec 2011 17:14:47 +0000
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Hi, I'm considering putting together an Internet-Draft for adding timezone headers to HTTP and I'd like to elicit feedback from yourselves (the HTTPWG) before I go any further. There has been previous discussion about adding support for timezones to HTTP, e.g. http://tools.ietf.org/html/draft-sharhalakis-httptz. The last update to that draft was (almost) two years ago. I have been in contact with the author of that draft. I'm still waiting for feedback. The feedback to that draft on this mailing list was mostly positive. Currently to display dates and times in a user's local timezone websites can apply two solutions. A user's timezone can be guessed by their location using the requesting client IP address. This does not account for user's who wish to have a timezone different to their current locations timezone. This mechanism breaks down when sites are accessed through intermediary servers. It also requires each server to implement their own guessing mechanism. The other way is to manually ask the user what timezone they would prefer and save their choice. This solution is laborious for the user and it must be manually updated by the user if they change timezones. What I would be proposing is to have a request HTTP header 'Accept-Timezone' that would obsolete the need for the approaches detailed above. The value of the header would consist of a timezone identifier from the Olson database. An example of the header, Accept-Timezone: Europe/London A response header, 'Content-Timezone' would be used by servers to signal that a response's content had been modified for a particular timezone. An example of this header, Content-Timezone: Europe/London which would signal that the response was modified for the 'London, UK' timezone. As this will lead to different content being returned for a URI I would stipulate in the draft that the Vary header should be used if the response has been modified for a particular timezone. Clients or intermediaries that understand the Content-Timezone header would use that value instead of Vary. An example: Vary: Accept-Timezone I believe a timezone identifier would be useful to more applications than just an offset from UTC as it allows for historical and future date/times to be converted accurately to a client's timezone. * If I raised an I-D does it seem likely that this would be something that the HTTPWG would endorse? I believe this is required to get past draft status. * I believe Vary would be enough to enable intermediaries/clients to differentiate between different responses. Is this correct? * Any other feedback would be appreciated. Thanks in advance, Matt Fenelon
Received on Tuesday, 6 December 2011 17:15:17 UTC