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.

Sign up for GitHub

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

Jump to bottom

org.springframework.web.servlet.mvc.method.annotation.ReactiveTypeHandler does not handle vendor-specific application/x-ndjson media types #26817

Closed
nlescure-pictet opened this issue Apr 16, 2021 · 3 comments
Closed

org.springframework.web.servlet.mvc.method.annotation.ReactiveTypeHandler does not handle vendor-specific application/x-ndjson media types #26817

nlescure-pictet opened this issue Apr 16, 2021 · 3 comments
Assignees
@simonbasle
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone
6.1.0-M1

Comments

@nlescure-pictet
Copy link

Hi,

At one point, the handler iterates over ReactiveTypeHandler#JSON_STREAMING_MEDIA_TYPES which contains two values: MediaType.APPLICATION_NDJSON and MediaType.APPLICATION_STREAM_JSON.

If a controller uses a custom vendor-specific "produces" streaming type such as application/vnd.myname.v1+x-ndjson (for API versioning for example), it won't "match" within the loop and the handler will not use a JsonEmitterSubscriber as expected.

Shouldn't ReactiveTypeHandler#JSON_STREAMING_MEDIA_TYPES contain the generic media type: application/*+x-ndjson so that it "includes" custom vendor-specific streaming type.

Thank you.
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Apr 16, 2021
@rstoyanchev rstoyanchev added the in: web Issues in web modules (web, webmvc, webflux, websocket) label Nov 10, 2021
@nlescure-pictet
Copy link
Author

Hi there,
Any update on that one ?

@simonbasle
Copy link
Contributor

I have discussed that one with the team and it appear a bit overcomplicated to add a customization path for that particular aspect. we agree that your suggestion of adding a wildcard subtype for that particular component is an acceptable middle ground.

@simonbasle simonbasle self-assigned this May 25, 2023
@simonbasle simonbasle added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels May 25, 2023
@simonbasle simonbasle added this to the 6.1.0-M1 milestone May 25, 2023
@nlescure-pictet
Copy link
Author

Great thanks !

simonbasle added a commit that referenced this issue May 26, 2023
@simonbasle
Polish ReactiveTypeHandler when checking wildcard ndjson subtype
3f14ebc 
This commit polishes the previous change, ensuring that if the request
uses a wildcard subtype with an ndjson suffix then the wildcard isn't
present in the response's Content-Type.

Insteand, in that case we would fall back to `applicatin/x-ndjson` (the
base ndjson media type), assuming that the requester is only interested
in the ndjson nature of the underlying representation and not in the
specific semantics of any subtype.

See commit 9332b3f
See gh-26817
mdeinum pushed a commit to mdeinum/spring-framework that referenced this issue Jun 29, 2023
@simonbasle @mdeinum
Have ReactiveTypeHandler consider +x-ndjson suffix as streaming
40b84be 
This commit adds `application/*+x-ndjson`, a wildcard media type which
covers all types that can be parsed as nd-json, to the list of media
types the ReactiveTypeHandler considers for a streaming response in
WebMVC.

As a result, a request which for example `Accept` the
`application/vnd.myapp.v1+x-ndjson` media type will generate a response
with the same `Content-Type`, with newline-delimited json objects being
streamed in the response body.

Closes spring-projectsgh-26817
mdeinum pushed a commit to mdeinum/spring-framework that referenced this issue Jun 29, 2023
@simonbasle @mdeinum
Polish ReactiveTypeHandler when checking wildcard ndjson subtype
adc0c11 
This commit polishes the previous change, ensuring that if the request
uses a wildcard subtype with an ndjson suffix then the wildcard isn't
present in the response's Content-Type.

Insteand, in that case we would fall back to `applicatin/x-ndjson` (the
base ndjson media type), assuming that the requester is only interested
in the ndjson nature of the underlying representation and not in the
specific semantics of any subtype.

See commit 9332b3f
See spring-projectsgh-26817
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@simonbasle simonbasle

Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Milestone
6.1.0-M1
Development

No branches or pull requests
4 participants
@rstoyanchev @simonbasle @spring-projects-issues @nlescure-pictet