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

SSE now works with preceding channel handlers such as SSL #394

Merged
merged 2 commits into from
Jul 23, 2015

Conversation

johanhaleby
Copy link

Previously it was not possible to connect to a SSE server that also used SSL (https). The reason is that SSEInboundHandler / SseChannelHandler added the ServerSentEventDecoder before the SSL decoder handler in the pipeline chain which made ServerSentEventDecoder operate on encrypted data. This pull requests corrects this by not adding the ServerSentEventDecoder first in the pipeline.

@NiteshKant
Copy link
Member

@johanhaleby thanks for the PR!

Looking at the code now, it seems that the if (!HttpHeaders.isTransferEncodingChunked((HttpResponse) msg)) check is unnecessary and we can unconditionally add the decoder after the SseChannelHandler. However, I do not have a way to reproduce the issue you are facing. Do you mind pointing me to a sample which does not work with the current release?

@johanhaleby
Copy link
Author

I discovered this when I was working with https support in Turbine (here's the link to that pull request). After a lot of investigation and trail-and-error I found that this was the problem. Unfortunately I couldn't write an automated test case to verify it. I discovered it while trying to combine SSE and SSL in Turbine. The changes made here and in Turbine made it work for our Hystrix stream that is using https.

@NiteshKant
Copy link
Member

ok @johanhaleby can you verify if turbine streams work over SSL when instead of the code in this PR:

if (!HttpHeaders.isTransferEncodingChunked((HttpResponse) msg)) {
                pipeline.addBefore(NAME, SSE_DECODER_HANDLER_NAME, new ServerSentEventDecoder());
                /*
                 * If there are buffered messages in the previous handler at the time this message is read, we would
                 * not be able to convert the content into an SseEvent. For this reason, we also add the decoder after
                 * this handler, so that we can handle the buffered messages.
                 * See the class level javadoc for more details.
                 */
                pipeline.addAfter(NAME, SSE_DECODER_POST_INBOUND_HANDLER, new ServerSentEventDecoder());
            } else {
                pipeline.addAfter(NAME, SSE_DECODER_HANDLER_NAME, new ServerSentEventDecoder());
            }

you change it to:

               pipeline.addAfter(NAME, SSE_DECODER_HANDLER_NAME, new ServerSentEventDecoder());

i.e. remove the check if(!HttpHeaders.isTransferEncodingChunked((HttpResponse) msg)) and unconditionally add the ServerSentEventDecoder to the pipeline after SseChannelHandler.

I did verify that SSE over plain HTTP works with this change. If this does work then I would like to instead make this change and remove the redundant check.

@NiteshKant NiteshKant added this to the 0.4.11 milestone Jul 22, 2015
@johanhaleby
Copy link
Author

@NiteshKant It seems to work without the if-statement. FYI this is our Nginx settings in production on the server I'm testing against:

proxy_buffering off;
proxy_cache off;
proxy_set_header Connection '';
chunked_transfer_encoding off;

I.e. transfer encoding is indeed off.

@johanhaleby
Copy link
Author

I've updated the pull request and removed the if-statement

NiteshKant added a commit that referenced this pull request Jul 23, 2015
SSE now works with preceding channel handlers such as SSL
@NiteshKant NiteshKant merged commit b72a94e into ReactiveX:0.4.x Jul 23, 2015
@NiteshKant
Copy link
Member

Thanks @johanhaleby !

@NiteshKant NiteshKant added the bug label Jul 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants