RE: questions -- clarifications requested

Paul Leach writes:
	...
 > As currently written, it seems that returning a Location: header is 
 > mandatory (even if the same Request-URI would do).

I don't think so.  Where do you get this?

	...

 > 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.

I don't think they're generally required, unless you need the functionality
they provide.

  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.
 > 
Fine.

 > Our disagreement stems from me focussing on the second case, and you on 
 > the first.  On the first case, I agree completely, now that I understand it.
 > 
 > I think that the language of section 8.19 on the Location header is at 
 > best misleading with respect to your desired POST behavior. (In 
 > addition to saying that the Location header "should" be returned, which 
 > is at odds with the statement for status code 200 in section 6.2.2 that 
 > it "may" be returned.)
 > 

8.19 doesn't say Location "should" be returned.  But I agree that the spec
should spell out how it is to be used by caches, at least a little,
since it is so important for cache implementers to get it right, and
it is so easily misunderstood.


 > The first sentence of section 8.19 says  "the Location response header 
 > field defines the exact location of the resource that was identified by 
 > the Request-URI".  For GET, this is true. In the POST case, it is not 
 > the resource identified by the Request-URI, but the location of the 
 > resource created by the POST.
 > 
Yes.

 > Just for the sake of concreteness, I propose the following replacement 
 > for the first sentence of section 8.19:
 > 
 > "If the entity-body in a response corresponds to a resource (or, in the 
 > case of HEAD, would correspond to a resource if it were present), the 
 > Location response header field defines the exact location of that 
 > resource -- even if it is the same as the Request-URI."
 > 
 > And the wording in section 6.2.2 should change to say that the response 
 > "should" include a Location header field, instead of "may", when the 
 > entity in the response corresponds to a resource.
 > 
I don't know -- I think you should look at the uses of "should" in
8.19 a little more closely.

 > I also propose the following addition the the end of the description 
 > for status code 200 in section 6.2.2:
 > 
 > "If the response entity-body describes the result of the action, and 
 > does not correspond to a resource, then a Location header field must 
 > not be included, and the fields related to caching (Expires, 
 > Last-Modified, etc.) are not allowed."
 > 
On first reading, that seems reasonable.

 > I believe that this will allow Shel's scenarios, as well as more dynamic ones.
 > 
 > Paul
 > 

--Shel

Received on Wednesday, 30 August 1995 14:42:02 UTC