- From: Jamie Lokier <jamie@shareable.org>
- Date: Fri, 9 Jul 2004 17:29:50 +0100
- To: Scott Lawrence <scott@skrb.org>
- Cc: Lisa Dusseault <lisa@osafoundation.org>, "Roy T. Fielding" <fielding@gbiv.com>, ietf-http-wg@w3.org
Scott Lawrence wrote: > > What do others think -- should PATCH always be able to work on unmapped > > URIs, or never? > > Why not leave it to the server? If the particular patch format requires > an existing resource and it's not there, the server can return a 4xx > error. I agree with this. What a patch format can operate on needs to be specified per patch format. That leaves scope for application-specific patch formats in future. It makes sense to say an unmapped URI SHOULD be treated the same as an empty representation if there is no patch-format-specific reason to do otherwise. By definition, a patch only applies correctly to a file with a certain known pre-existing content. So a client always knows when a patch format can be be used, and when it can't, given known server capabilities and known pre-existing representation. Because of this it seems fine to allow particular patch formats to only apply to certain representations. For example, an XML or executable patcher -- or one which only patches ZIP files. Why not? The client, when computing the patch, already knows if the format is appropriate, so it's fine and not at all confusing to return a 4xx error if a patch is applied to the wrong kind of representation -- just the same as if a patch is applied e.g. to the wrong size. So it's inappropriate to say a patch format MUST apply to empty representations. Because: its inappropriate to say a patch format MUST apply to all byte streams, or anything else; there's nothing wrong with patch formats that apply to only a subset. However if a patch format does apply to empty representations, it makes sense that the same format SHOULD be usable to patch a non-existent one into existence. Imho, -- Jamie
Received on Friday, 9 July 2004 12:29:58 UTC