RE: Advanced Status Reporting and XML vs HTML

Got any suggestions for how to do this?

You may disagree with my assessment of the requirements/goals of this
project, but here's the way I see it:

1) We must not use a header to return advanced status information.  There's
too much of it.  Servers must be able to return, in a single response,
information about multiple resources, much like today's 207 Multistatus.
The simplest example of this is a MOVE of a large directory:  the server can
report every locked child resource, rather than force the client to discover
one by one which ones are blocking the MOVE.

2) We should not return mime/multipart to clients that are used to receiving
a regular HTML body.  IIS and Apache both currently return ordinary HTML
bodies on error messages, and browsers are used to displaying those.  We
don't want to screw those clients up.

3)  Having an extra 25 characters in the client's request is preferable to
having multiple formats returned in the server's response.  This counts also
for embedding XML inside the HTML body:  why add an extra 100-1000
characters in the server response if it can be avoided by having clients
that want advanced status send this extra header?  Some folks have slower
uplinks than downlinks, but I still think that an extra 25 chars in the
client response will be a price they will find worth paying.  Ask the client
developers -- I think they're in favour of this.

4)  Keeping the additional information around on the server for clients to
query later may be unacceptable to server implementors.  It requires the
server to maintain state and do extra disk writes.  It must come up with two
formatted result bodies, rather than just one.  Since the server must handle
many client requests, this does not seem the way to let the server scale.
Are you aware of any server implementors who would find this option
acceptable?  It's unacceptable to me!

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding
> Sent: Tuesday, December 19, 2000 3:44 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: Advanced Status Reporting and XML vs HTML
>
>
> > So, my proposal is to kill two birds with one stone.  We pretty
> much agreed
> > that the client should advertise its support for this feature
> in requests,
> > presumably by adding a header.  It's straight-forward to allow
> this header
> > to provide information on what kind of thing the client wants
> to receive.
>
> I don't think so.  Every time the client advertises support for a feature
> it adds to the request latency of every request and creates a new variable
> against which content selection algorithms must apply.
>
> This goes back to the discussion of content negotiation in HTTP/1.0.
> Accept headers are a bad idea.  They have always been a bad idea.
> A better solution is to provide the client with the primary content
> choice and a means of obtaining the new content. Or, if the alternatives
> are small, as in this case, just include the status in such a way that
> it has no adverse impact on clients that do not understand it.
>
> ....Roy

Received on Wednesday, 27 December 2000 22:40:21 UTC