Re: PUT and ETag (or Last-Modified-Date)...

While looking over PUT as part of the range discussion, I
looked over the 201 (Created) response.

There are two problems, as I see it:

1) the cache validator of a modified or recently created resource is
not returned in the response.  Now say I've PUT a 1 megabyte entity,
and then have to turn around and get it again, just to get a cache
validator for later conditional requests).  The proxy marks its cache
stale.  You'd like a proxy to be able to revalidate its cache entry
after a put without necessarily having to transfer the entity.  The
proxy can't just use the old validator; it will be always the wrong
value, and so you'll always transfer the entity.

200 series responses return entities, themselves, so presumably the
cache validator returned in the response applies to that entity, not
that of a resource that might just have been put.

This problem can be ignored right now, but the caching consequences
for PUT are not wonderful.

One possible solution, given the change in 2) below that removes
the entity that might be sent in 201 Created, is to define that
any cache validator returned in a 200 or 201 from PUT applies to
the resource being PUT.

What should we do?  Leave things as is?  Punt to 1.2?  Am I confused?

2) the definitions of 201 and 202 overlapped pretty badly; this
problem is mostly independent of 1) though affects the possible
solution to problem 1:

201 Created said:
"The origin server SHOULD create the resource before returning the
201 status code. If the action cannot be carried out immediately,
the server MUST include in the response body a description of when the
resource will be available; otherwise, the server SHOULD respond with
202 (Accepted)."

Pretty complicated, confusing, and ill-defined.
202 Accepted is the non-immediate case, for operations that may
happen later.

I've changed this to say:

"The origin server MUST create the resource before returning the 201
status code. If the action cannot be carried out immediately, the
server should respond with 202 (Accepted) response instead."

As Roy pointed out in private mail,
immediate is hard to define, but seems appropriate.

Anyone see any problems with this change?  I think it needs
to be made even if we punt on 1.
			- Jim

Received on Sunday, 2 June 1996 14:30:55 UTC