- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Tue, 12 Oct 1999 14:58:02 -0700
- To: w3c-dist-auth <w3c-dist-auth@w3.org>
Um, wait a minute, this still doesn't make sense. If a server uses your recommended oredering for the propstat XML element and sends the status first, then starts streaming data out of its property store, and then detects an error ... there's no way to put that error into the response, since you've already sent the status, right? Assuming the server isn't streaming the data out doesn't work either -- if the server reads the entire property out before marshalling the response, then it can detect ahead of time that there was an error, and just not send any information at all for the property, thereby avoiding the case that motivates the ordering change in propstat. > >Uh...but now I'm wondering whether this actually makes sense. > >Is there any case where the operation failed but you get a prop > >with an actual value in it? > > The only cases that seem to make sense to me are those where the server > manages to retrieve partial content before the error occurs. Presumably > these would result in error code (500 Internal Server Error). > > >> > One rule in the DTD states: > >> > <!ELEMENT propstat (prop, status, responsedescription?) > > >> > > >> > I suggest that this is modified to read > >> > <!ELEMENT propstat (status, responsedescription?, prop) > > >> > - Jim
Received on Tuesday, 12 October 1999 17:58:44 UTC