- From: Matt Timmermans <mtimmerm@opentext.com>
- Date: Tue, 30 Oct 2001 14:11:27 -0500
- To: "'Jim Whitehead'" <ejw@cse.ucsc.edu>, "'Roy T. Fielding'" <fielding@ebuilt.com>
- Cc: "'WebDAV'" <w3c-dist-auth@w3.org>
GETSRC is evil: 1) It's strictly less powerful than the source link. What are you going to do about synthetic _collections_, and multiple synthetic resources with the same source, or a synthetic document with a source collection (i.e., a compiled source tree)? 2) It's incompatible with existing DAV clients. Everyone who writes a DAV client has to know that they must set Translate: F if they want to work properly with IIS. You'd force everyone to retrofit to call GETSRC in place of GET. 3) It doesn't even satisfy Microsoft's requirements. Translate: F works for all methods, not just GET. 4) It breaks the symmetry that HTTP requires between GET and PUT. > -----Original Message----- > From: Jim Whitehead > > The source link was never implemented. > > The two reasons I have heard for this (there may be more) are: I think the big one is that, in most cases, it isn't necessary. If the web site has a source tree, it's not unreasonable to expect the web site authors to know where that source tree is. They are the authors, after all. > (a) Server implementors did not want to handle the namespace > complexity of > automatically creating new areas of the namespace for source > resources. That > is, on most servers, the source resources would be > "synthetic" -- the server > would be making up the URL for the source resource, and would > be managing > interactions with this synthetic resource. There isn't a requirement to automatically synthesize parts of the namespace. In fact, what I can easily do Today does everything but fill in the source links. I just have to map two virtual directories to the same location -- one view tree at http://me.com/* and one source tree at http://me.com/~src/*. On the latter directory, I can disable script execution, grant source editing and browsing permissions, and require stronger authentication. What Today's web servers don't do is fill in the source link, because in most cases they can't know how to do it properly. Oh sure, a Web server might be able to supply a sourcelink for /cgi/mycgi.exe, but it can't provide a source link for /cgi/mycgi.exe/doc1, because it doesn't know where my CGI gets its information from. Similarly, of course, the Web server can't implement GETSRC on /cgi/mycgi.exe/doc1. It's the CGI's job to fill in those source links if it wants to. > [...] > I think existing client UIs could handle a standard mechanism > to get at 1 source representation for a resource. I do not think they can handle a > mechanism that provides access to multiple source representations. You're right, but a "source representation" is not necessarily an entity body. All we really need is some language that tells a client how to extract a URI for the source from the source link property, i.e., a single source link, or a "main" source link, or some such thing. What the source link gets you is a File/Edit item on the menu when you view the page in a Web browser. The appropriate thing to do when that item is selected is clear if you have a single source link -- you PROPFIND it to determine DAV:resourcetype and DAV:getcontenttype, and then open the link in whatever client application is appropriate for editing that type of resource. If the source resource is a jsp or asp page, then the source file will open in the appropriate editor. If the source resource is a collection, then it will open in your default WebDAV explorer. GETSRC has a much reduced scope. > Efforts > to do so will, like the source link, be ignored. I think it > is instructive > that the only mechanism that has gained any traction so far > is the Translate > header, which provides access to one source representation. That's not all that Translate: does. Translate: F disables script processing. If you PUT to a CGI with Translate: F, you overwrite the CGI. If you leave out the header, then the CGI processes the request. If you PROPFIND mycgi.exe with Translate:F, you get properties of the executable file. Without the header, you might get DAV:resroucetype=DAV:collection and some children. If you PROPFIND mycgi.exe/somedir with Translate: F, you get 404 or 409. If you leave out the header, the CGI might give you the properties of a synthetic DAV-compliant resource. In short, Translate: F and GETSRC are not equivalent in functionality, and MS's decision to use Translate: F does not support adding GETSRC to the RFC. Moving on... There is, however, a real problem with the source link in 2518 -- it's a property, and only works for resources that are DAV-compliant. A CGI, for example, is a simple way to synthesize a Web page. There is no reason for that synthetic resource to be DAV-compliant at all. CGI authors don't want to go through all the trouble of implementing PROPFIND just so they don't have to remember where the source tree is. How many other methods will CGI authors have to implement to convince the browser that it should do a PROPFIND in the first place? If we want to provide a really useful link to source representations, it needs to be a simple header that CGIs can just stick in their responses. We could define the DAV-source: <URL> header to point the the "primary source" for that resource. We can keep the existing source link for DAV-compliant synthetic resources if we describe the mapping between the two.
Received on Tuesday, 30 October 2001 14:12:34 UTC