Re: This is not "this is not a date"

>I have a suggestion: instead of coming up with a new syntax
>for "this is not a date" (when the existing date syntax, horribly
>inefficient and hard-to-parse as it is, has at least more or
>less been tamed by implementors) perhaps we can get by with
>something a little simpler.
>
>For example, we could say
>
>	If the sender is required to send a Date header
>	by some part of this specification, and is unable
>	to generate a current HTTP-date value, it SHOULD
>	send a legal HTTP-date value that is provably in
>	the past.
>
>For example, send
>	Date: Thu, 01 Jan 1970 00:0:01 GMT
>
>As far as I can tell, this will not lead to any more trouble
>than simply omitting the Date header.  It also seems to be
>legal according to section 14.19 of -rev-01.

Ummm, we already have a syntax for "this is not a date"  -- the lack
of a Date header field.  Why should we send garbage on the wire?
I think we should just change the specification so that it properly
handles the case where there is no Date header field.  That would be
the more robust way of specifying it in any case.

....Roy

Received on Friday, 12 December 1997 21:36:47 UTC