W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

Re: Source property, SHTML, and SSI

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
Message-ID: <9808051650.aa03880@paris.ics.uci.edu>
>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.


>> 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.

Received on Wednesday, 5 August 1998 19:59:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:17 UTC