Why is the return type of POST oauth/request_token "text/html" when it is clearly not HTML?

[JornWildt]

It seems rather odd to me that the response content-type of a POST to oauth/request_token is “text/html” when the content is clearly not HTML, but rather application/x-www-form-urlencoded.

The makes it problematic to work with frameworks that actually believes what the server is telling about its payload.

Thanks, Jørn Wildt

[episod]

We’ve attempted to resolve this in the past to hilarious effect. It’s definitely possible that we’ll rectify this in the future, but there are unfortunately enough circumstances where returning the appropriate content-type on these two methods causes more harm than good.

[JornWildt]

Would it help if you looked at the incoming “accept” header? If the HTTP client told you that, yes, it certainly expects “application/x-www-form-urlencoded” then you could return that media-type identifier instead of text/html (and leave that for those clients that do not use the accept header).

To me that would look like a win/win situation (but I certainly have no knowledge of all the problems you have experienced).

/Jørn

[trumpi]

One issue I am having with the text/html response type is that the .NET WebClient does not handle it correctly out of the box, and some extra configuration is required to the form url decoder formatter so that it will handle these responses as form url encoded responses.

Additionally, if this hacking of the form url decoder formatter happens in shared code, then all text/html responses will be treated as form url encoded responses, which is not desirable.

While all of this can be worked around, having the incorrect response type does increase the difficulty of implementing clients.