- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 22 Oct 2010 09:26:58 +1100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Daniel Stenberg <daniel@haxx.se>, Robert Brewer <fumanchu@aminus.org>, HTTP Working Group <ietf-http-wg@w3.org>
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: > 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 > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 21 October 2010 22:27:35 UTC