Allow more complex content types. #58
Conversation
We use Content-type headers that look like this: Content-Type: application/vnd.api.v1+json; charset=utf-8 and curently slumber barfs on these, refusing to decode. This change allows you to specify, say, format='json' when initializing the API object and deserialize properly. I'm not sure if this is the totally right spot for this code, but I wanted to bring this to ya'lls attention.
| stype = s.get_serializer() | ||
| try: | ||
| return stype.loads(resp.content) | ||
| except: |
There was a problem hiding this comment.
Should be at least except Exception
|
@philipn This bug is a bit annoying for working with local wiki. I patched my slumber copy with this workaround, but should we make a better fix? If you are recommending slumber on the localwiki site for use, then it should be something that actually works. |
|
We will be ditching the complex content types in LocalWiki API because of issues like this On Aug 17, 2013, at 6:21 AM, Jason Moore [email protected] wrote:
|
|
Such content-types are really useful for many things, and this bug should be fixed. This PR just needs a small change (see my comment) and a test. |
|
Actually, if you have an API that returns While requests always returns a unicode object which is just as wrong in the first case, it at least says somewhere in the doc that it assumes things are unicode by default (iirc). And specifying the charset does make it work properly in this case. So imho, this fix is not suited for fixing the problem completely though I don't know yet where to hook this exactly. |
We use Content-type headers that look like this:
Content-Type: application/vnd.api.v1+json; charset=utf-8
and curently slumber barfs on these, refusing to decode. This change
allows you to specify, say, format='json' when initializing the API
object and deserialize properly.
I'm not sure if this is the totally right spot for this code, but I wanted
to bring this to ya'lls attention.