W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

RE: driveway.com / cadaver interop

From: Yaron Goland <yarong@Exchange.Microsoft.com>
Date: Thu, 27 Jan 2000 13:13:55 -0800
Message-ID: <7DE119D3D0E15543874F7561EECBDBED0261A0E6@BEG.platinum.corp.microsoft.com>
To: "'Joe Orton'" <joe@orton.demon.co.uk>, support@driveway.com
Cc: w3c-dist-auth@w3.org
A server is always free to return extra properties since clients are always
able to tell if a response contains the properties they are interested in. A
client that fails in this scenario would be properly viewed as broken as,
even if the standard prohibited returning extra properties, a real world
client MUST be flexible enough to handle a broken server that did the wrong
thing in this case.

That having been said, I wouldn't support specifying that a server MUST NOT
return extra properties as I don't think this requirement would enhance
interoperability and it would prevent some potentially useful scenarios.

I realize that a server returning extra properties could be considered a
D.O.S. attack but since the server is the "service" and since the client can
kill the TCP connection, I find this argument to be a bit strained.

> -----Original Message-----
> From: Joe Orton [mailto:joe@orton.demon.co.uk]
> Sent: Thursday, January 27, 2000 11:34 AM
> To: support@driveway.com
> Cc: w3c-dist-auth@w3.org
> Subject: driveway.com / cadaver interop
> In the response to a PROPFIND with the following body:
> <?xml version="1.0"?>
> <propfind xmlns="DAV:">
>   <prop><getcontentlength/><getlastmodified/><resourcetype/></prop>
> </propfind>
> the driveway.com server will include the DAV:supportedlock element for
> non-collection resources, which seems wrong, although I can't find
> anywhere in 2518 which actually says so. There should be some kind of
> requirement that servers only return the *requested* 
> properties for this
> type of PROPFIND requests, shouldn't there? A MUST 
> requirement would be
> nice.
> joe
Received on Thursday, 27 January 2000 16:15:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:21 UTC