2006/5/7, Toru Marumoto <[EMAIL PROTECTED]>:
On 5/7/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
> *This* is nice and simple:
> {{{
> HTTP/1.1 500 Internal Server Error
> Server: xxxxxxxxx
> Date: xxxxxxxxx
> Content-Type: text/plain
> Content-Length: 31
>
> Can't connect to the DB server.
> }}}
>
I agree "that" is simple.
But please! please wait. That is not simple as it looks to me.
(1)Not easy for I18N
(2)Not user friendly
(1) In Japan, we have a LOT, I mean A LOT, of charset
commonly used, such as Shift-JIS, EUC-JP, JIS, UTF-X,
etc.
HTTP/1.1 500 Internal Server Error
Server: xxxxxxxxx
Date: xxxxxxxxx
Content-Type: text/plain;charset=utf-8
Content-Length: nnn
さよーなら
If it was a XML document, an XML Parser will take
care of all the messy encoding conversions.
Don't forget that any text/plain stream is also a valid
text/xml-external-parsed-entity stream.
(2) A client have no way of knowing what the body is.
Is it meant to be displayed to a user(such as my mather)?
or is it just a junk(such as a core dump or trace log)?
Atom won't help you without some more constraints and processing
rules, and/or extension elements.
Who is generating it? a proxy maybe?
If a proxy is generating the error, it might not (is likely not to)
know about the Atom Protocol, so it won't give you an appropriate Atom
response.
Yes, it looks simple, and probably easiest way to implement.
I'm clearly not against some "standard error response format", but:
* not in the "core", this is not required for the protocol to "just work"
* not as a mandatory response format (also see above about
limitations wrt to proxies)
So this can really be developped as a companion RFC.
--
Thomas Broyer
