[Twisted-Python] HTML shoudl not be baked into twisted.web HTTP implementation
terry at jon.es
Wed Dec 9 17:08:00 EST 2009
>>>>> "James" == James Y Knight <foom at 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.
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.
More information about the Twisted-Python