* Asbjørn Ulsberg <[EMAIL PROTECTED]> [2006-11-27 20:55]: > Am I the only one pondering and worrying about what the > different server implementations will respond to invalid client > requests (as, for example, an invalid Atom document)? How can > the client implementors be interoperable and compatible with > each other and every server implementation if the specification > says absolutely nothing about what to expect when something > goes wrong? > > HTTP covers some of the possible errors one might encounter, > but I believe there are several cases in APP where errors might > occur that HTTP does not cover and that server implementors > will treat very differently. In most server application > frameworks, unhandled exceptions give the response "500 Server > Error". Is that the appropriate response to give on most > errors? Which errors should yield which 4xx response? Is this > not an issue? How can a client tell the user how to correct > something if the client have no idea what response to expect > from the server?
I get your concern and to some extent I share it, but I’m unsure about how it could be addressed. If we assume that servers can implement wildly different feature sets and special cases, then there is a huge number of conditions which the server would need to be able to somehow signal. I don’t know how we can allow for that. A special error document XML vocabulary for those cases where the HTTP status is not granular enough would be an option. Some document making suggestions about what error status codes to use in which circumstances could also help unify expectations. But the scope of any such endeavour will be huge… Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
