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

> -----Original Message-----
> From:	Scott Lawrence [SMTP:lawrence@agranat.com]
> Sent:	Friday, December 12, 1997 9:00 AM
> To:	HTTP Working Group
> Subject:	Re: This is not "this is not a date"
> 
>   We have the same problem with Date and Expires; proxies may add them
>   (section 13.5.2) even when the origin server used an empty value
>   when the digest was generated.  As I see it, we have four
>   alternatives:
> 
	[Joshua Cohen]  Im confused.
	If the purpose of this discussion is simply to have a date
placeholder,
	what are the effects of using a token marker date, such as the 
	epoch beginning , ie 0 unix time.

	I imagine that existing 1.0 proxies will be using last-modified to
determine
	the age of an entity, not date:.
	Presently, many proxies will not cache an item without a L-M header
	or expires:.  

	We cant fix any old 1.0 proxies that are deployed today, but I cant
	imagine how they will be worse off in this case.
	For 1.1, we can define the epoch time as a value that
	means "I have no idea what time it is".
	Newer 1.1 proxies which implement the new age-calculation formula
	should be aware of the null date value.

	As far as a proxy adding a date: header...
	Assuming the proxy adds a date header from its own clock on a
response,
	and there are nested proxies, will each successive proxy be
incorrectly
	calculating the age? 
	someone tell me if Im wrong, but we are saying:
	"Age = age of the locally cached entity" NOT "Age= age of the entity
in question ( since it was created/modified)"
	right?

	Josh Cohen
	Objfun: We should keep dating to a minimum in the wg, "This is not a
date", we're just friends :)
	  
>

Received on Sunday, 14 December 1997 03:58:24 UTC