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

CXF-8545 - support POST requests from SseEventSource #813

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

timothyjward
Copy link
Contributor

Add support for POST requests from the SseEventSource

Builds on top of PR #812 (for testing)

Create a failing test to show that SSE doesn't work for POST resource methods
Copying the request headers causes the response to gain a Content-Length if the request had a body. This breaks the streaming nature of the SSE response
It is perfectly valid to return an event stream from a POST method, but currently there is no way to connect to it with the JAX-RS client. This commit adds support for connecting to event streams using POST methods by supplying an entity to be used as the POST body.
@reta
Copy link
Member

reta commented Jun 9, 2021

Thanks for the PR, @timothyjward , I believe we should take a step back and think about what we would like to implement first. So we want to provide the option to use POST for SSE events but the SseEventSource is GET-oriented and does not have the means to provide the request payload: this is by design and I believe we should not alter that anyhow. This is what the consumer of this API would expect. Probably, the conclusion is we have to define the APIs which would explicitly model SSE-over-POST, it should not be squeezed into SseEventSource. May be something along these lines:

public interface SsePostEventSource<?> {
    void open(Entity<?> payload);
    void close();
    boolean isOpen();
    void register(Consumer<InboundSseEvent> onEvent);
    ...
}

Now, the important question is: what should happen on reconnect? Should the same request payload be sent to the endpoint over and over again? Or should it be up to consumer to decide? I inclined to think that we should use second option since it is very likely the payload could be outdated already. So the API should support that, again just rough idea:

    ...
    void register(Provider<Entity<?>> onReconnect);
    ...

But it may not be sufficient though, the LAST_EVENT_ID_HEADER could come very handy for example. Anyway, there are few things to think about, I hope it makes sense, thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants