RE: questions -- clarifications requested

Shel writes:
] No, the intent is that if the POST returns something that it would
] make sense for a GET to get from a cache later, that it should be
] possible.  If this is desired, the server should (a) either give the
] response a URI with Location that later GETs will correspond to, or
] (b) arrange for future GETs to use the same request-URI as the POST
] did, and (c) arrange for the document to be cacheable by proper use of
] Expires, Last-modified, etc.  It need not be the case that all returns
] from POST be cached and that links be provided to fetch it from the
] cache, it only needs to be *possible* so that people who need this
] functionality can have it.

As currently written, it seems that returning a Location: header is 
mandatory (even if the same Request-URI would do). This makes  web 
pages that are even more dynamic than the shopping basket type, where 
there is no URL that could be used to refetch the result entity of a 
POST, impossible.

Let me summarize how I would prpopose to satisfy the needs of both 
styles and see if you agree:

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.

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

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.

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

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

Paul

Received on Wednesday, 30 August 1995 13:39:47 UTC