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

Re: Bindings and Other Methods (Section 10)

From: John Stracke <francis@ecal.com>
Date: Wed, 15 Sep 1999 15:42:14 -0400
Message-ID: <37DFF696.3BDDB6DD@ecal.com>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
"Slein, Judith A" wrote:

> e would like to say the simple, straightforward thing:  That for any of
> these methods, the results of applying the method through one binding are
> identical to the results of applying the same method with the same headers
> and body through another bindings to the same resource.
> What prevents us from saying this are executable resources, which generate
> responses dynamically and may be sensitive to which Request-URI is used to
> access them.  If we try to take these executable resources into account, we
> are reduced to saying things that are so open-ended that they place no
> enforceable constraints on the behavior of GET, PUT, etc., when applied
> through different bindings to the same resource.

Why exactly is this a problem? Me, I'd consider it a feature; if I write code
that's sensitive to the Request-URI, it's probably for a good reason.  I may
want to be able to write a script once and place bindings to it in different
places that behave differently according to their location.  In fact, I *have*
written such a script.  On my personal site, I don't have access to the logs,
so I've placed index.cgi scripts in various directories that I want to monitor;
they log the hit and return a 302 to redirect to Index.html.  Since I didn't
want to maintain N copies of the script, most of them are symlinks.  Since the
302 requires an absolute URI, the script looks at the Request-URI to figure out
where to redirect to.

|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Round up the usual disclaimers.              |
|francis@ecal.com|                                             |
Received on Wednesday, 15 September 1999 15:42:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:18 UTC