Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

decoded_content isn't decoding charset if content-type is application/json #36

Closed
alambike opened this issue Aug 31, 2016 · 8 comments · May be fixed by #99
Closed

decoded_content isn't decoding charset if content-type is application/json #36

alambike opened this issue Aug 31, 2016 · 8 comments · May be fixed by #99

Comments

@alambike
Copy link

alambike commented Aug 31, 2016

In the same way that decoded_content makes charset decodification in text and xml content types, is not correct make this too in application/json ?

Something like (I'll make a PR if it is acceptable):

if ($self->content_is_text || (my $is_xml = $self->content_is_xml) || (my $is_json = $self->content_is_json)) {
@vanHoesel
Copy link
Member

See other issue
#72 (->decoded_content should decode application/json, etc [rt.cpan.org #82963])

See merge-request
#90 (Always charset decode, regardless of content type.)

Conclusion

decoded_content SHOULD NOT decode using the charset given in the MIME type, but only for text/* types; application/json is binary data, and the charset param is only useful for a body-content processor, just as any param would be for any other binar format.

This issue SHOULD be closed

@dracos
Copy link

dracos commented Mar 11, 2018

I assume you meant SHOULD at the start of your Conclusion?

@vanHoesel
Copy link
Member

it says ... SHOULD NOT .. but only for text/*

@dracos
Copy link

dracos commented Mar 11, 2018

Right, it does, but you do want to decode for text/*, surely?
"decoded_content SHOULD decode using the charset given in the MIME type, but only for text/* types" is what you are saying from your comments on the other tickets.

@vanHoesel
Copy link
Member

and we SHOULD only do it for that ... or be super intelligent guessing

@dracos
Copy link

dracos commented Mar 11, 2018

Right; all I'm saying here is that your conclusion is incorrectly written for your argument, nothing more! :)

@vanHoesel
Copy link
Member

as described in #99, unless we add extra parameters or an entire new method, this can not be solved without breaking any existing API based on JSON.

@oalders
Copy link
Member

oalders commented Apr 3, 2018

Closing this as we've got some progress in #99

@oalders oalders closed this as completed Apr 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants