>>>>> "James" == James Y Knight <f...@fuhm.net> writes: James> Essentially every web server on the internet responds with HTML to James> error conditions, so you should probably modify your client.
But there are plenty of clients that can't or don't want to or shouldn't have to handle HTML. James> As I said, I'm all for customizability, but returning HTML bodies James> for error pages is unambiguously the correct default. I agree. This is, I think, a good example of where respecting the Accept header makes sense. If no Accept header is sent, it's the same as sending */*, in which case t.web could do as it currently does and send text/html. But if there is an Accept header you can pass it and the range of response types you have to a library like http://code.google.com/p/mimeparse/ and it will tell you what to send back. Although making an XML and a JSON response available just in case feels a bit arbitrary, it's no more arbitrary than an HTML response that was designed to look good to a human with a browser. They reply contents just need to be documented. We got this complaint with FluidDB (using t.web), and you also see it floated in public from time to time - I saw someone complaining on Twitter about it just the other day. Another way to mitigate this, at least in the context of errors is to put more information into returned headers. We added an X-FluidDB-Error-Class and X-FluidDB-Request-Id that don't require anyone to dig through a body in some perhaps unpredictable or unhandled format. In simple cases you can then just omit a payload and a Content-Type altogether. Terry _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
