- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Wed, 05 Aug 1998 16:49:59 -0700
- To: ccjason@us.ibm.com
- cc: w3c-dist-auth@w3.org
>Roy, You say, "IF the server is maintaining the source file under a >differnt URL than GET..." That's what I said in my proposal, but is >that what we're typically going to be seeing? I have no idea. It's >just the first WEBDAV'ish way that I thought of for handling it. Let >me know if your expectations are. Anyone. It is the way I would implement it. Apache already does the dual URL thing for directory indexes, content negotiation, and a variety of other handlers for indirectly produced content. >> then a PUT on the latter URL should >> result in an error or redirection to the source URL. > >I think I understand what you're saying here. "latter URL" here means the >one who's GET results in processing of the SSI. Yep. >> The server can >> determine that from the URL and content of the PUT. Otherwise the >> author is likely to be confused about what is being authored. > >I don't think I understand what you're saying here. Determine what? >Determine if it's an old fashion PUT or a WebDAV PUT? I'd appreciate >it if you restated this. I don't know what "that" refers to. The server can tell the difference between a mistaken PUT on a derived resource and a PUT intended for the source resource, usually by looking at the content-type of the PUT request. This isn't going to happen very often since there are not many non-WebDAV PUT-enabled tools. In any case, my point was that it is easier to control access to a generated resource if the source handle and generator handle are two different URI. It is also much easier to explain to a user, since the source can be moved around as a file, whereas the generator handle is just a mapping in the server namespace. ....Roy
Received on Wednesday, 5 August 1998 19:59:27 UTC