Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC

From: Ilya Kirnos <[email-masked]>
Date: Wed, 01 Aug 2001 20:20:47 -0700

Inspection of OPTIONS and PROPFIND responses showed:

     1) Oracle IFS only supports DAV class 1, and doesn't return an ALLOW
     header
     on OPTIONS,

That's correct, iFS DAV does not support locking in its current version.

     2) <getetag> is "getetag_blah" for all resources,

Yes, that's a known hole.  We're looking at cache interaction for our next
release, this will fall under that.

     3) It tries to return <getlastmodified> in RFC format, but uses it's
     locale
     for formatting, which obviously will not produce an RNC formatted
     date when
     your language isn't english,

Tell me more about the problem?  Where are we using the locale?

     4) It tries to return <creationdate> in RFC format (and fails in the
     same
     way), while this should be in ISO8601 format,

Does the spec say it has to be ISO8601?  I remember that Web Folders didn't
seem to like that, so we put in a hack at the last minute to make it display
dates correctly.

     5) <getcontentlanguage> (when not "unknown") is set to language
     strings like
     "ENGLISH" (which I think is incorrect according to section 14.13 of
     [RFC2068])

Yep, that's a bug.  Will fix it in our next release.

Let me know if you found any other issues.

Thanks.

-ilya

Julian Reschke wrote:

> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Ilya Kirnos
> > Sent: Tuesday, July 31, 2001 3:59 AM
> > To: [email-masked]
> > Subject: RE: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
> >
> >
> > > This would be fine with me as well.  It basically says that if a LOCK
> > > is applied to an unmapped URI, the LOCK is automatically preceded with
> >
> > > a PUT with a zero-length body.  As Stefan and Lisa say, having a
> > > zero length resource remain when the LOCK is removed will not cause
> > > a problem with existing clients, and clients that care about IIS
> > already
> > > cannot expect to be able to apply MKCOL to a "lock null" resource.
> >
> > > If we didn't already have clients that expected a LOCK on an unmapped
> > > URI to succeed, I'd prefer to just say that the LOCK just returns 404
> > > on an unmapped URI, but I can live with this compromise proposal.
> >
> > I agree: my first choice would  be for abandoning the concept of a null
> > lock, but if people feel strongly they should be kept, the semantics
> > should be changed to allow the server to create an actual file to track
> > the lock.
> >
> > Among other things, this allows other protocols to have at least a shot
> > at playing nice with DAV locks.  This point (interoperability with other
> > protocols) has been brought up a couple of times in this discussion
> > already, and is an important consideration for the server I'm working on
> > (Oracle iFS), and I suspect for others as well.  It can't just be
> > ignored.
>
> Hi.
>
> If you happen to work on Oracle IFS, would it be possible to give us some
> feedback on the WebDAV compliance issues listed in
>
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0253.html>
>
> ?
>
> Thanks,
>
> Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 2 Aug 2001 06:56:18 +0200

> From: Ilya Kirnos [mailto:[email-masked]]
> Sent: Thursday, August 02, 2001 5:21 AM
> To: Julian Reschke
> Cc: [email-masked]
> Subject: Re: rfc2518 issue: DEFER_LOCK_NULL_RESOURCES_IN_SPEC
>
>

As far as I remember, with WebIFS installed on a german Windows2000 server
machine, it will generate something like "Montag, 12. Jan 1998 08:25:56 GMT"
rather than "Monday, 12-Jan-98 09:25:56 GMT". This means, you can't use the
standard locale date formatting routines for WebDAV (or HTTP) RFC dates
(unless you force it to use the english language).

> Does the spec say it has to be ISO8601?  I remember that Web

Yes (<http://greenbytes.de/tech/webdav/rfc2518.html#PROPERTY_creationdate>).

> Folders didn't

Well. The way it's done now, MS web folders won't even *mount* the directory
because of the broken date format.

I think I remember that an old version of MS web folders only accepted
ISO8691 dates if they came with a data type attribute a la

<creationdate xmlns:dt="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/"
dt:dt="dateTime.tz">2001-08-01T14:38:27Z</creationdate>

This isn't nice, but at least it doesn't break any client. Newer versions of
web folders don't seem to have this problem.

> Let me know if you found any other issues.

Due to the bugs mentioned, I currently can't use WebIFS with anything beside
some special test scripts. Microsoft Webfolders (and Office) will reject
them, so it's hard to do any serious testing.

Thanks for the feedback!

Julian