Subject: RE: Ideas: GETSRC & MULTIPUT

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 29 Oct 2001 16:17:46 -0500

Why isn't GETSRC just a GET on the DAV:dst of the DAV:source property?
(If it is just a shorthand for this, I'm against the redundant marshalling
of this request through a new method).

As for MULTIPUT, that sounds fine to me, but it should be accompanied by
a MULTIGET, which would allow reading of a resource and its metadata in
one transaction.

Cheers,
Geoff

-----Original Message-----
From: Jim Whitehead [mailto:[email-masked]]
Sent: Monday, October 29, 2001 3:14 PM
To: WebDAV
Subject: Ideas: GETSRC & MULTIPUT

I'm interested in the list's thoughts on two ideas for DAV improvements:

The first is to introduce a GETSRC method to support access to the
unprocessed source of a resource. This would decouple the dynamic response
of a resource (GET) from its static source (GETSRC).

The second is to introduce the MULTIPUT method to support "PUT with
PROPPATCH" scenarios. MULTIPUT would accept some subset of multipart MIME
packages and atomically write them to the server. This would support the
update of a resource and its metadata in one transaction.

- Jim

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 29 Oct 2001 22:35:18 +0100

Geoff,

I'd like to see how the DAV:dst in WebDAV can support what Microsoft is
doing with their Translate header (namely, having the source and the dynamic
content at the same URL).

See also my comments in

<http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JulSep/0149.html>

Julian

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Monday, October 29, 2001 10:18 PM
> To: WebDAV
> Subject: RE: Ideas: GETSRC & MULTIPUT
>
>

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 29 Oct 2001 16:10:35 -0800

> of this request through a new method).

The source link has not been implemented. We don't currently have two
interoperable implementations. Thus, according to IETF policy, the source
link goes away in the revision of 2518.

At that point, we have no mechanism for accessing the unprocessed source of
a link. Hence, no duplication of mechanism.

Being a pragmatist, the source link hasn't worked. To me, this suggests a
different approach. I like a new method better than the Translate header,
since we're really asking for a different aspect of the state of the
resource than a GET.

> a MULTIGET, which would allow reading of a resource and its metadata in

I think the case for MULTIGET is much weaker. A client cannot easily
implement a PUT/PROPPATCH transaction with existing methods. If one of the
two methods fails, it's hard for the client to rollback. That is,
MULTIPUT/MPUT/PKG is not a network optimization -- it's accomplishing
something that is difficult, if not impossible, for a client to do right
now.

But, if a client does a LOCK (exclusive), GET, PROPFIND, it is guaranteed to
get the properties that are consistent with the body of the resource.

- Jim

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 29 Oct 2001 16:37:15 -0800

> link goes away in the revision of 2518.

If you change the protocol to add GETSRC, then there is no point in
revising RFC 2518 -- it would have to recycle at Proposed.  I think it would
make more sense to have the server and client developers explain why they
did not implement it and then come up with a solution that they will implement.

I certainly don't want to implement a GETSRC method -- that instantly doubles
the server's access control complexity and response codes.

....Roy

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 29 Oct 2001 17:19:21 -0800

> revising RFC 2518 -- it would have to recycle at Proposed.

My assumption is that revising 2518 will take some time. If a new mechanism
for getting access to the source link is developed, and sent to proposed in
a separate RFC, I suspect we could get two interoperable implementations
before the end of the 2518 revision period, and hence include the new
mechanism, since it too woul dbe at Draft status then.

>  I
> think it would make more sense to have the server and client developers
> explain why they did not implement it and then come up with a solution
> that they will implement.

I am all in favor of developing a solution client and server implementors
will code.

> the server's access control complexity and response codes.

Other ideas?

- Jim

---

From: Alan Kent <[email-masked]>
Date: Tue, 30 Oct 2001 13:57:56 +1100

I am uneasy about a single URL being effectively bound to two resources
(GET and GETSRC return different resources). It opens a potential
can of worms in that every HTTP method (HEAD, PROPFIND, LOCK, ...)
then potentially needs to be duplicated.

And how do I know that GETSRC will work? (Is it defined for all
resources no matter what type they are?)

Personally I would feel more comfortable with either the current
'source' scheme, another HTTP header field applicable to all requests,
or a parameter on the URL or something (/foo.html and /foo.html;getsrc).

I can see the cleaness of making one URL computed from the other
(identical in the proposed scheme, computed in the ;getsrc parameter
scheme above) but I dislike one URL identifying multiple resources and
the riple through all the other methods that would be required.

Alan

---

From: "Dylan Barrell" <[email-masked]>
Date: Tue, 30 Oct 2001 09:07:50 -0500

The reason for MULTIPUT is so that servers can enforce property rules on
resources when they are created. MULTIGET doesn't add any additional value
so I could live without MULTIGET.

--Dylan

> Sent: Monday, October 29, 2001 4:18 PM
> To: WebDAV

---

From: "Nicholas Atkinson" <[email-masked]>
Date: Tue, 30 Oct 2001 16:31:07 -0000

Hi there

Is there any documentation available which describes what Microsoft are
doing with their Translate Header?  (I have tried the archive of this list
but the search facility is not working).

Does the Apache web server support something similar?

nik

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 30 Oct 2001 10:03:03 -0800

I know a little bit about the philosophical design, hope this helps.

The "Translate" header is a bit of a mis-nomer.  You could probably more
accurately call it "Author-Mode" and switch the true/false values.

When Translate is not present, or Translate: F, it means the client is a
browser, or an authoring client in browsing mode.  The HTTP/WebDAV should
therefore apply appropriate transforms, such as generating dynamic content.

When Translate: T is in the request, it means the client is in authoring
mode.  The most clearly affected method is GET because the source is
returned instead of the transformed result, but the header is actually sent
on all requests from the client at this time.  This means that a server is
potentially capable of using the Translate header to decide how to calculate
'getcontentlength' in response to a PROPFIND -- it may even be possible to
calculate the length of the source when Translate is True and the length of
the generated content when Translate is False.

I believe that for many methods (COPY, MOVE) the behaviour is the same
whether Translate is T or F.  Note however that the information about what
mode the client is in is still there, should the server ever need to make a
distinction between two behaviours on the basis of whether the client is
authoring or not.

Obviously this doesn't work directly for CGI scripts or (this is the
Microsoft solution after all) ISAPI.  I think it's possible to turn on
WebDAV access to the files that compose one of these types of Web plugins,
but since the model is more file access than Web access, these would have
different URLs and there might not be a clear way of seeing the link between
the dynamic URL and the source URLs.  Still, there hasn't been clear demand
from customers for shared authoring of these types of things right on the
Web server -- I'd suspect most serious Web programming teams would use a
real source server, perhaps a staging sever, and a production server, all
with different URLs.

Lisa

> [mailto:[email-masked]]On Behalf Of Nicholas Atkinson
> Sent: October 30, 2001 8:31 AM
> To: WebDAV
> Subject: Re: Ideas: GETSRC & MULTIPUT
>
>
> Hi there
>

---

From: Greg Stein <[email-masked]>
Date: Wed, 31 Oct 2001 02:47:01 -0800

> Does the Apache web server support something similar?

Nope. Generally, I recommend that people set up a second set of URLs to
access the CGIs, PHP scripts, or whatever. That second space can disable the
CGI/PHP/whatever execution and treat all content as text/plain. The URLs can
be somewhere else on the server, or a different port.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/