201 created on PUT Method etc

Henrik and I found a problem with the 1.1 put when
testing against the linemode browser.

When the document exists, I send back 204 with
entity headers including the content-version.

This works fine because there is no body.

However, when a new entity is created, I send
201 but cannot send the entity headers on the new
resource because there can be a separate entity body.

The result is that the client will have to do an additional
head to know the resulting entity version etc etc.

It seems to me that, in the first case, the "200 or 204" in the
spec should be dropped the 200.

In the second case, it seem to me that either 201 should not
return a body or a different return code like a 204 should be
used, thus obviating the need to do an extra operation to collect
the information needed to handle versioning.

Additionally, the content-version and derived-from headers should
be moved into the spec body.

Who wants to write file and not know if there is a version conflict? Hunh?

Naturally, the 100 codes should be required in 1.1 so we don't have another
botch job on our hands.  Note that I close the connection whenever I reject
a 1.0 client on a put because I know the lossage is a'coming right behind.
Most of the time, the client will have to authenticate.  (this may be fixed
by now.)

BTW, we getting some nice bug reports from testing.

Received on Sunday, 18 August 1996 00:44:37 UTC