Re: Issue 248: client "Date" requirements

On 18.10.2010 08:50, Daniel Stenberg wrote:
> On Mon, 18 Oct 2010, Mark Nottingham wrote:
>
>>> "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).
>
> 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

Received on Thursday, 21 October 2010 14:01:25 UTC