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

From: Stefanos Harhalakis <[email-masked]>
Date: Sat, 9 Jun 2007 21:23:56 +0300

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 <[email-masked]>
To: Stefanos Harhalakis <[email-masked]>

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 
tell 
> 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."

-Stut

-------------------------------------------------------

---

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 09 Jun 2007 22:01:09 +0200

> on non-PUT/GET requests? Is it for privacy issues?

I think it has more to do with Date often being considered an entity
header rather than just a general message header. 

This restriction go all the way back to the first IETF draft of RFC1945
(HTTP/1.0) btw, but not in the draft I could find before that..

First draft I could find where the text is present

http://tools.ietf.org/html/draft-ietf-http-v10-spec-00  March 8, 1995

And last draft I could find where the text is NOT present

http://ftp.ics.uci.edu/pub/ietf/http/history/draft-fielding-http-spec-01.txt December 19, 1994

A quick scan of the mailinglist archives for the period didn't come up
with any obvious discussion regarding this.

Regards
Henrik