Subject: Issue 248: client "Date" requirements

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Oct 2010 18:46:03 +0200

Hi,

the spec currently says:

"Clients SHOULD only send a Date header field in messages that include a 
payload, as is usually the case for PUT and POST requests, and even then 
it is optional. A client without a clock MUST NOT send a Date header 
field in a request."

(this comes from RFC 2616).

This is very wrong:

"SHOULD only .. and even then it is optional".

So, if it's optional, it's MAY. I don't believe we need to say that 
clients "MAY" send a Date header :-).

Can we simplify that, or even remove it?

(see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/248>)

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 11 Oct 2010 18:54:21 +0200

>clients "MAY" send a Date header :-).

It's saying that a client must not send a Date header if the client has
no clock, it should not send a Date header of there is no payload, and
it may send a Date header otherwise. The wording may not be optimal but
the intent seems clear.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Oct 2010 18:57:32 +0200

> it may send a Date header otherwise. The wording may not be optimal but

Except for the payload question: that's all common sense, right?

Best regards, Julian

---

From: "Robert Brewer" <[email-masked]>
Date: Mon, 11 Oct 2010 12:21:37 -0700

Julian Reschke wrote:
> the spec currently says:
> 
> "Clients SHOULD only send a Date header field in messages that include
> a payload, as is usually the case for PUT and POST requests, and even
> then it is optional. A client without a clock MUST NOT send a Date
> header field in a request."
> 

I read that as "Clients SHOULD NOT send a Date header field in messages
that do not include a payload. The header is optional for messages that
do include a payload, as is usually the case for PUT and POST. A client
without a clock MUST NOT send a Date header field in a request."

I'd be interested to know why they should or not in either situation,
however. I don't really see the use case.

Robert Brewer
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Oct 2010 15:03:33 +0200

> however. I don't really see the use case.

I have no idea what the requirements are good for (except for 
not-to-send-what-you-do-not-know :-).

As the spec says "MUST" (with exceptions) for servers, it probably 
should say *something* about clients, though.

"Clients MAY send a Date header (when a clock is present)".

?

Does anybody recall where the "requirement" with respect to payload 
comes from? Is it just about keeping request messages small when the 
Date is of no interest?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Oct 2010 15:37:04 +1100

> "Clients MAY send a Date header (when a clock is present)".

This is a bit too brief IMO; the advice about not sending it without a payload is useful (because it saves bytes, as you noted).

--
Mark Nottingham   http://www.mnot.net/

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 18 Oct 2010 08:50:39 +0200 (CEST)

On Mon, 18 Oct 2010, Mark Nottingham wrote:

> This is a bit too brief IMO; the advice about not sending it without a 
> payload is useful (because it saves bytes, as you noted).

Can I also point out that the "(when a clock is present)" part is unnecessary 
since if it is a MAY any implementor that doesn't have a clock surely will 
then consider not sending a date or will have another way of figuring out the 
timestamp to include there...

-- 

  / daniel.haxx.se

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 Oct 2010 16:00:18 +0200

On 18.10.2010 08:50, Daniel Stenberg wrote:
> Can I also point out that the "(when a clock is present)" part is
> unnecessary since if it is a MAY any implementor that doesn't have a
> clock surely will then consider not sending a date or will have another
> way of figuring out the timestamp to include there...

Absolutely.

So let's try to get this fixed.

The current text is:

(1) "Clients SHOULD only send a Date header field in messages that 
include a payload, as is usually the case for PUT and POST requests, and 
even then it is optional."

(2) "A client without a clock MUST NOT send a Date header field in a 
request."

(1) seems to be equivalent to:

"Clients MAY send a Date header field in messages that include a 
payload, as is usually the case for PUT and POST requests."

Does this mean "MUST NOT" send when there is no payload? Why not, except 
for saving bytes? This is not required for interop, it's just advice.

That being said; is the advice really good? What does the usefulness of 
date information have to do with the presence of a payload?

The only reason I see for having client advice here is that the text 
begins with server advice. Sending general headers is optional anyway 
unless otherwise stated. And not sending an optional header you can't 
populate is just common sense.

So, how about:

"The Date header field can be used in requests as well; in order to keep 
request messages small, clients are advised not to send it when it 
doesn't convey any useful information, as it is usually the case for 
requests that do not contain a payload."

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Oct 2010 09:26:58 +1100

I think this is reasonable. One editorial niggle: it's easier to scan for this if the paragraph begins with 'clients' as before; e.g.,

"Clients can use the Date header field in requests as well..."

Cheers,

On 22/10/2010, at 1:00 AM, Julian Reschke wrote:

> (1) "Clients SHOULD only send a Date header field in messages that include a payload, as is usually the case for PUT and POST requests, and even then it is optional."
> 
> (2) "A client without a clock MUST NOT send a Date header field in a request."
> 
> "Clients MAY send a Date header field in messages that include a payload, as is usually the case for PUT and POST requests."
> 
> Does this mean "MUST NOT" send when there is no payload? Why not, except for saving bytes? This is not required for interop, it's just advice.
> 
> That being said; is the advice really good? What does the usefulness of date information have to do with the presence of a payload?
> 
> The only reason I see for having client advice here is that the text begins with server advice. Sending general headers is optional anyway unless otherwise stated. And not sending an optional header you can't populate is just common sense.
> 
> So, how about:
> 
> "The Date header field can be used in requests as well; in order to keep request messages small, clients are advised not to send it when it doesn't convey any useful information, as it is usually the case for requests that do not contain a payload."
> 
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Oct 2010 11:56:59 +0200

On 22.10.2010 00:26, Mark Nottingham wrote:
> ...

Yup.

"Clients can use the Date header field as well; in order to keep request 
messages small, they are advised not to include it when it doesn't 
convey any useful information (as it is usually the case for requests 
that do not contain a payload)."

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1047>

Best regards, Julian