RE: questions -- clarifications requested

Larry Masinter writes:
	[ Paul wrote: ]
 > > For POST, if the response entity-body, in the language of the spec, 
 > > "contains the result of the action", and "corresponds to a resource", 
 > > and the server wishes the result to be able to be cached, then the 
 > > Location: header is required, as is proper use of Expires, 
 > > Last-Modified, etc.  If the response entity-body "describes the result 
 > > of the action", and does not correspond to a resource, then Location: 
 > > must not be present, and Expires, Last-Modified, etc., relating to 
 > > caching are not allowed.
 > 
 > I wouldn't trust an "Expires" that didn't actually come along with the
 > document being served. There's a security hole otherwise; Joe
 > 'Microsoft-is-Evil' might put up a form <click here> that returns
 > 

>From what are you construing that there would or could be Expires
headers sans the document they correspond to?

 > ================================================================
 > Location: http://www.microsoft.com
 > Expires: 01 Jan 2001 12:00:00 pST
 > 
 > <body>I am the evil Borg.</body>
 > ================================================================
 > 

This really argues against all such use of the Location header,
doesn't it?   Not just the Expires header that goes along with it?
Location in 2xx responses could be used in just this way
in any case.  Maybe there just needs to be a restriction that Location
in 2xx headers must be on the same server as the request URI. 
(This would be similar to the security precautions in the Netscape
cookie proposal).

 > 
 > Why don't we leave it as 'Can't cache POST' and not bother gilding
 > this particular lily?
 > 
 > 

Wouldn't we have to *change* it to 'can't cache POST'?  Where is it
written now that POST outputs can't be cached?  And isn't this a
different issue anyhow?

	fearing we're all on different wavelengths as usual,

			--Shel

Received on Wednesday, 30 August 1995 16:57:02 UTC