W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

Fwd: Re: [PHP] [RFC] HTTP timezone

From: Stefanos Harhalakis <v13@priest.com>
Date: Sat, 9 Jun 2007 21:23:56 +0300
To: ietf-http-wg@w3.org
Message-Id: <200706092123.56896.v13@priest.com>

Hello once again,

  I've sent some RFCs to a couple mailing lists and this is one of the replies 
I got. Do you happen to know why the client-side Date header is discouraged 
on non-PUT/GET requests? Is it for privacy issues?

  I've already replied to this saying that changing the semantics of 
the 'Date' header would result in another version of HTTP.

----------  Forwarded Message  ----------

Subject: Re: [PHP] [RFC] HTTP timezone
Date: Saturday 09 June 2007
From: Stut <stuttle@gmail.com>
To: Stefanos Harhalakis <v13@priest.com>

Stefanos Harhalakis wrote:
> On Saturday 09 June 2007, Stut wrote:
>> However, I like the idea but would modify it slightly such that it send
>> an RFC 2822 formatted date which will include the timezone but would
>> also allow the server to determine if the datetime on the client is
>> wrong. This can be important for applications that make extensive use of
>> client-side technologies such as Javascript.
> I've already thought about providing the full time but I didn't find any 
> applications. Can you provide some examples about its usage? How can you 
> whether a user has wrong time and not wrong timezone?

You can't. But just because we can't immediately think of a use doesn't 
mean uses don't exist.

Now, to the point. Including the time would only slightly modify RFC 
2616 which states that "Clients SHOULD only send a Date header field in 
messages that include an entity-body, as in the case of PUT and POST 
requests, and even then it is optional" (section 14.18).

I don't know the reason for that clause excluding other requests, but 
you would be well-advised to find out why before submitting your RFC. In 
any event, adding a new header seems daft to me when there is an 
existing header that is currently acceptable in certain cases that 
includes the information your new header would provide.

In my opinion your RFC should recommend that "Clients SHOULD send a Date 
header with every request unless the client does not have a clock. A 
client without a clock MUST NOT send a Date header field in a  request."


Received on Saturday, 9 June 2007 18:25:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC