On 5/8/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
HTTP/1.1 500 Internal Server Error Server: xxxxxxxxx Date: xxxxxxxxx Content-Type: text/plain;charset=utf-8 Content-Length: nnn さよーなら
What if the charset parameter was missing. A client has to guess(no good). What if it was Content-Type: text/plain;charset=utf-7 or Content-Type: text/plain;charset=utf-8 or Content-Type: text/plain;charset=utf-16 or Content-Type: text/plain;charset=shift-jis or Content-Type: text/plain;charset=euc-jp or Content-Type: text/plain;charset=iso-2022-jp and list goes on ... I think same thing happens in other countries like China, Tiwan etc. How many charset encoding do I have to support? Beside, my past experience taught me that Content-Type: charset parameter is often wrong because of misconfiguration of Apache. (Apache's default configuration adds wrong charset if not specified.)
> 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.
I din't know about this. Can MSXML Parser load and parse that?
> (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.
At least I get a title, a summary, a detailed contents and links and which app server software to blame for, which is very important by the way ;-), if it was the Atom Entry. Then I could display the title and the summary and "Details" bottan to show full content etc.
> 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.
That's ok I realized that a proxy usually don't return response body.
> 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.
The idea of companion RFC is great. I thought "The Atom Publishing Protocol is all about pushing around Atom Entries." http://www.xml.com/pub/a/2005/09/21/atom-store-web-database.html I mean, If the Atom Publishing Protocol was all about pushing around *anything*, then an Atom client became just another Web browser. Happily we all at least agree on "we need some standard error response format". So, how about, in a seperate rfc, introducing Atom Error Document? or stick with Atom Entry Document or completely new format? cheers
