- From: Tim Ellison <Tim_Ellison@uk.ibm.com>
- Date: Fri, 22 Jun 2001 09:54:16 +0100
- To: ietf-dav-versioning@w3.org
If a server tells a client that it is HTTP/1.1 compliant, then the client can rightly expect the Expect: header to be supported since it is required by the spec. Say the client sends Expect: and the server never 100-Continues. The options for the client writer are: (1) Scream at the server implementer about what a heap-'o-junk that server is, preach the value of standards, take their custom elsewhere, etc. or, (2) accept that the server states it is compilant, but code around it. In this case, don't rely on that server feature. Switch to DeltaV... Say a server states that a resource is a <DAV:resourcetype><DAV:activity/></DAV:resourcetype>. The client goes to PROPPATCH the DAV:subactivity-set, which is required by the activity feature, and the server responds with 501 Not Implemented (or whatever). The options for the client are exactly the same, complain and/or don't rely on that feature. Only this time the client was fooled into thinking that the resource _would_ support that live property because it advertises it is an activity-type. Had the client asked for the DAV:supported-live-property-set it would have seen that the DAV:subactivity-set was not present and not attempted the operation. If anything this is preferrable. Stating <DAV:activity/> in the resourcetype is *just* a shorthand for stating the properties and methods that an activity resource is expected to support. Regards, Tim Ellison Java Technology Centre, MP146 IBM UK Laboratory, Hursley Park, Winchester, UK. SO21 2JN tel: +44 (0)1962 819872 internal: 249872 MOBx: 270452 ------------------ "Lisa Dusseault" <lisa@xythos.com> wrote: I just ran across an explanation for a RFC 2616 feature which leads me to believe that the feature should be implemented for all methods -- the Expect header (See separate post to w3c-dist-auth for details). Do all your DAV servers support the Expect header properly on all methods? I suspect not. CLients don't actually send it. And yet, it's required by HTTP/1.1 This is an example of theoretical "non-compliance". A required feature is missing. Oh horrors! Note that it doesn't seriously impede interoperability. Perhaps nobody was sure how to use the feature. Shrug. The implication of a situation like this is that designers of a specification cannot foresee how everything is going to fall out. Not all "required" features may be implemented, and this might be OK. If there was some kind of "allowed-headers-set" that could be queried, a compliant client should see "Expect" in there for all resources and all methods -- yet it won't. Relying on a set of methods and properties supported in order to determine type is brittle because of these kinds of failures of perfect foreknowledge. For all Geoff's wisdom, it's conceivable that some REQUIRED live property will end up not being supported by some, most, or all servers. And that would ruin a client's ability to use the supported-*-set values to see what type things are. We're human, and we could be wrong. Please design a system that takes that into account, and does not entirely break down if we do not predict the future completely accurately. Lisa
Received on Friday, 22 June 2001 04:54:22 UTC