Re: Why it's bad to rely on other information to determine type

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