Affects Version/s: 2.1.2, 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.4.0, 2.4.1, 2.5.0, 2.5.2, 2.5.3, 2.6.0, 2.7.0
Fix Version/s: None
CLE Team Issue:Yes
When accessing Bookmark content types (URLs) from content hosting via WebDAV, the WebDAV service sends a redirect to the client. This is undesirable behaviour, because it causes the client to resolve and download the actual content pointed to by the URL rather than the metadata (URL).
In a context where a large number of bookmarks are in a folder which is copied to a local Windows folder for example, this could take a long time as the client resolves & downloads all the files. The original context (URL) of the files is lost, and worse, if one copies this folder back to a Sakai Resources folder via WebDAV, the bookmarks would be replaced by the actual file contents.
So while this behaviour may be useful in some contexts, it should be disabled by default.
Some alternative behaviours could include dynamically mapping bookmark file types to file types appropriate for particular client OSes; for example Windows stores link shortcuts (bookmarks) as .url files which look like this:
However, it's not clear whether a single behaviour would be appropriate for all client OSes, or whether the best-case scenario may be to attempt to detect the client OS, perhaps by looking at the user-agent string.
-------- Original Message --------
Subject: Re: Bookmarks in Resources and WebDAV
Date: Thu, 11 May 2006 11:34:14 -0400 (EDT)
From: Seth Theriault <firstname.lastname@example.org>
To: Stephen Marquard <email@example.com>
Stephen Marquard wrote:
> This is kind of cool, but a little unexpected. Is this a Windows phenomenon
> or is there some special handling in the WebDAV code?
Stephen gladly provided me with an example URL:
Originally, I thought the rendering was a Windows thing. It's not.
On Mac OS X Tiger, if you "cat" from the command-line the mounted file
via /Volumes, you get the raw html. on Mac OS X Panther, you can do
anything with the file.
On WinXP NetworkPlaces, I wasn't able to open the "file" directly, but
when I copied it to a local folder, there is a slight delay. When I
open the new local file, I see the raw HTML.
Some DAV sniffer logs (against 2.1.2 on qa2-us.sakaiproject.org) show
what is really going on:
--> C05 --> S06 ==== (148.121) Request <GET /dav/group/6fcbf698-251e-4039-80aa-d54acd1e5908/OSGRID%20Home%20Page HTTP/1.1>
--> C05 --> S06 GET /dav/group/6fcbf698-251e-4039-80aa-d54acd1e5908/OSGRID%20Home%20Page HTTP/1.1
--> C05 --> S06 User-Agent: WebDAVFS/1.4.1 (01418000) Darwin/8.6.0 (Power Macintosh)
--> C05 --> S06 Accept: /
--> C05 --> S06 If-Modified-Since: Wed, 10 May 2006 16:30:22 GMT
--> C05 --> S06 Authorization: Basic c2x0MDpzbHQw
--> C05 --> S06 Connection: keep-alive
--> C05 --> S06 Host: merlin:8090
--> C05 --> S06 ==== Body 0 bytes
<-- C05 <-- S06 ==== (148.163) Response 302 to <GET /dav/group/6fcbf698-251e-4039-80aa-d54acd1e5908/OSGRID%20Home%20Page HTTP/1.1>
<-- C05 <-- S06 HTTP/1.1 302 Moved Temporarily
<-- C05 <-- S06 Server: Apache-Coyote/1.1
<-- C05 <-- S06 Pragma: No-cache
<-- C05 <-- S06 Cache-Control: no-cache
<-- C05 <-- S06 Expires: Wed, 31 Dec 1969 19:00:00 EST
<-- C05 <-- S06 Set-Cookie: JSESSIONID=slt0.qa2-us; Path=/
<-- C05 <-- S06 Location: http://www.opensciencegrid.org/index.php?option=com_frontpage&elMenu=Home
<-- C05 <-- S06 Content-Length: 0
<-- C05 <-- S06 Date: Wed, 10 May 2006 16:31:31 GMT
<-- C05 <-- S06 ==== Body 0 bytes
Something is telling DAV to send out a 302 when accessing this file,
which it appears to understand. Would this be ContentHosting?
For anyone who cares, this seems to be an early (and incomplete)
implementation of RFC 4437, "WebDAV Redirect References Protocol,"
formally published in March 2006:
The Sakai DAV Servlet seems to not be sending the required
"Redirect-Ref:" header (in violation of section 6 of the 1999 version
or section 5 of the current version of the RFC). But that doesn't seem
to matter too much to some of the clients.