Uploaded image for project: 'RESTEasy'
  1. RESTEasy
  2. RESTEASY-1776

Sse feature should only be enabled when resource method only produces "text/event-stream" and is injected with @Context SseEventSink .

    Details

      Description

      1- The current Sse feature enabling policy goes againt media type negotiation rules in all cases described below.
      Also it's error prone and confusing since it lets user believe that a same resource can produce both text/event-stream and any standard media type (application/xml, applicaion/json ...)

      • 1st case:

      Let's consider following resource and a user request with Accept: application/xml, text/event-stream

         @GET
         @Produces(MediaType.APPLICATION_XML)
         public Response resourceMethod(@Context SseEventSink sseEventSink){
      	   ...
         }
      

      We are expecting the returned media type to be application/xml instead it will be text/event-stream.
      More, SseFeature will be enabled although the resource method does not produce text/event-stream.

      • 2nd case:

      Let's consider following resource and a user request with Accept: application/xml;q=0.9, text/event-stream;q=0.5

         @GET
         @Produces({MediaType.APPLICATION_XML, MediaType.SERVER_SENT_EVENTS})
         public Response resourceMethod(@Context SseEventSink sseEventSink){
      	   ...
         }
      

      We are expecting the returned media type to be application/xml instead it will be text/event-stream.

      • 3rd case:

      Let's consider following resource and a user request with Accept: application/xml, text/event-stream

         @GET
         @Produces({"application/xml;qs=0.9", "text/event-stream;qs=0.5"})
         public Response resourceMethod(@Context SseEventSink sseEventSink){
      	   ...
         }
      

      We are expecting the returned media type to be application/xml instead it will be text/event-stream.

      • 4th case:

      Let's consider following resource and a user request with Accept: application/xml;q=0.9, application/json;q=0.5

         @GET
         @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON, MediaType.SERVER_SENT_EVENTS})
         public Response resourceMethod(@Context SseEventSink sseEventSink){
      	   ...
         }
      

      We are expecting the returned media type to be application/xml instead it will be text/event-stream.

      2- The current Sse feature enabling policy inject SseEventSink instance and start asynch processing even if the resource medthod does not have any @Context SseEventSInk parameter.
      So it leads to resource leaking since:

      • the AsyncContext is never completed in case of real async processing (using org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher servlet class)
      • or thread not being notified in case of "fake" async processing (using org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher servlet class)

      Following resource is an example:

      	@GET
      	@Produces(MediaType.SERVER_SENT_EVENTS)
      	public void resourceMethod() {
      		...
      	}
      

      So in order not to be confusing for users and to be consistent with the existing media type negotiation rules (since it's not the goal of Sse feature to re-implement them) and also prevent resource leaking let's stick to the spec definition of a SSE resource method:

      9.3 Server API
      ...
      A resource method that injects an SseEventSink and produces the media type text/event-stream is an
      SSE resource method.
      

      and by saying "produces the media type text/event-stream" I"m wondering it means "only produces the media type text/event-stream" given the inconsistency of all previous cases above, the SseEventSink java doc and all example that can be found about JAX-RS Sse.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                asoldano Alessio Soldano
                Reporter:
                nicolas.n Nicolas NESMON
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: