Re: VERSION-CONTROL on an existing resource

    <Greg>
    Section 9.1.1 shows the use of a VERSION-CONTROL on an
    existing resource. However, it responds with a 201 (Created).
    I'm thinking that it should be a 200 (OK) or a 204 (No Content)
    since it is not creating the Request-URI.
    </Greg>

<tim>
I agree that 200 (OK) is probably more appropriate now that I have read
RFC2616 definitions again with this case in mind.
</tim>

    <Greg>
    RFC 2616, 10.2.2 states that the created resource should be
    returned in a Location: header (presuming it is different from
    the Request-URI). As I read it, it may even mandate a Location:
    header for the 201 (Created) response.
    </Greg>

<tim>
hmm, the location header likely would not be different to the request-uri
for a vanilla PUT to a new location.
</tim>

    <Greg>
    I think it might be a bit whacky for VERSION-CONTROL to return
    the location of the version history, so I'd recommend changing
    the response (for an existing, versionable) resource to one of:

        1) 200 (OK) with a body that specifies the URIs of
        the initial version and the version history.

        2) 204 (No Content)


    The first is certainly more informative for smart clients.
    </Greg>

<tim>
I don't mind which of these are adopted.
</tim>

Tim Ellison
Java Technology Centre, MP146
IBM UK Laboratory, Hursley Park, Winchester, UK.
tel: +44 (0)1962 819872  internal: 249872  MOBx: 270452

Received on Thursday, 16 November 2000 05:17:49 UTC