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

Allow specifying HTTP response Content-Type without losing default charset [SPR-13631] #18209

Closed
spring-projects-issues opened this issue Nov 2, 2015 · 5 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Nov 2, 2015

Sébastien Deleuze opened SPR-13631 and commented

As discussed in #18178, @RequestMapping "produces" attribute is used for mapping purpose, but also to generate the response content type.

With converters like MappingJackson2HttpMessageConverter when the default MediaType also specify the charset to use, overriding this attribute with "produces" = MediaType.APPLICATION_JSON_VALUE will change response encoding, even that not what most users are expecting (most of them just want to narrow the mapping without affecting the charset).

The goal of this issue is to find if there is a way to easily make it possible to override the mapping related to produces without "reseting" the charset used.


Affects: 4.2.2

Issue Links:

Referenced from: commits c385427

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Nov 2, 2015

Sébastien Deleuze commented

See also this comment about the potential cause of this issue.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Nov 2, 2015

Rossen Stoyanchev commented

Just a quick note that this is not only about the produces condition. The Content-Type used in the response may also come from the "requested" content type as determined through a ContentNegotiationStrategy. For example path extension "json" registered against "application/json" will have the same effect.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Nov 3, 2015

Manuel Jordan commented

Hello

The Content-Type used in the response may also come from the "requested" content type as determined through a ContentNegotiationStrategy. For example path extension "json" registered against "application/json" will have the same effect.

Has sense… perhaps a kind of interceptor should be applied to return always with UTF-8. Of course the user "perhaps" should not be aware about that.

Even more, related with the previous point, in the coming weeks I am going to do my own detailed experiments working with Rest. It in case the RestTemplate sets the Accept to only Json and the content data returns with the weird characters.

My original post #18178 was tested only through a Web Browser. No tested yet through a RestTemplate client.

-Manuel

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Feb 23, 2016

Sébastien Deleuze commented

Rossen Stoyanchev Could you please review the fix I implemented with this commit?

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Feb 29, 2016

Sébastien Deleuze commented

I have updated the commit with Rossen feedback about ObjectToStringHttpMessageConverter and StringHttpMessageConverter, and will merge it shortly in master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants