- From: Tim Ellison OTT <Tim_Ellison@oti.com>
- Date: Wed, 13 Oct 1999 10:11:24 -0400
- To: ejw@ics.uci.edu (Jim Whitehead), w3c-dist-auth@w3.org (w3c-dist-auth)
You're right -- I can't think of a case where there is both an 'a priori' error and data. I'll withdraw my request. Thanks Tim ---------- >From: Jim Whitehead >To: w3c-dist-auth >Subject: RE: WebDAV DTD >Date: Wednesday, October 13, 1999 9:06AM > ><<File Attachment: HEADER.TXT>> >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 Wednesday, 13 October 1999 10:13:27 UTC