- From: Lisa Dusseault <lisa@xythos.com>
- Date: Wed, 27 Dec 2000 19:38:16 -0800
- To: "Roy T. Fielding" <fielding@ebuilt.com>, <w3c-dist-auth@w3.org>
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