ANCM/IIS ServerSentEvents won't work correctly (due to caching?)

[moozzyk]

When using ServerSentEvents the messages pushed to the client are not delivered immediately. Rather they are cached somewhere and are delivered when subsequent messages are being sent.
When I tried this my client (JavaScript) was always one message behind - i.e. when I pushed a message from the server the client would receive not the message I pushed but the previous one. This does not happen when using Kestrel directly.
Also we hit this when using SignalR JS Client (https://github.com/aspnet/SignalR-Server/issues/221) and also in a completely different environment when prototyping for new SiganlR.

[Tratcher]

You mean buffering?
Try disabling the dynamic compression module in web.config.

[moozzyk]

How does that affect non-serverSentEvent scenarios? (Also, I don't think it's required when running SignalR using the old stack and IISExpress/IIS)

[Tratcher]

In Asp.Net 4 SignalR uses a hack to disable dynamic compression per request by removing the Accept-Encoding header from the request. This doesn't work anymore because we're running out of process.

[moozzyk]

Would it make sense to disable dynamic compression if the response content-type is text/event-stream?

[Tratcher]

Seems too specific. The real question is how can the back-end process tell the front end not to buffer/compress on a per-response basis.

[muratg]

Do we need to update the template for web.config if this is required?

[moozzyk]

My feeling is that disabling dynamic compression for the entire site if you want to use Server Sent Events is too general.

[Tratcher]

Agreed, we want something per-reqeuest, but we can disable it temporarily to confirm that's the problem.

[Tratcher]

I found a workaround where setting the Content-Encoding=identity disables dynamic compression in IIS/Express. We could have the IISMiddleware implement DisableResponseBuffering and add this header. This wouldn't require any changes to ANCM or IIS, and would work on a per-request basis.

I'm still writing some integration tests to see how compression behaves if we enable in in the app behind IIS/Express.

[moozzyk]

I can confirm that it fixed ServerSentEvents transport.

[Tratcher]

The content-type is text/event-stream and IIS/Express compresses text/* by default. It's possible use an existing web.config setting to exclude text/event-stream:

        <httpCompression>
            <dynamicTypes>
                <add mimeType="text/event-stream" enabled="false" />
            </dynamicTypes>
        </httpCompression>

[muratg]

Slightly related: do we have a similar problem with nginx? Does it do things like dynamic compression?

[Tratcher]

https://www.nginx.com/resources/admin-guide/compression-and-decompression/

[Tratcher]

Unfortunately Content-Encoding: identity is not allowed per spec.
https://tools.ietf.org/html/rfc2616#section-3.5

 identity
        The default (identity) encoding; the use of no transformation
        whatsoever. This content-coding is used only in the Accept-
        Encoding header, and SHOULD NOT be used in the Content-Encoding
        header.

https://tools.ietf.org/html/rfc7231#section-8.4.2
identity: Reserved (synonym for "no encoding" in Accept-Encoding)

[Tratcher]

Another variation of the workaround: IIS won't compress the response if it Content-Encoding is already set. If the app used the response compression middleware, or if SignalR choose to set Content-Encoding: gzip and compress the respionse itself then IIS would not. However, GZipStream in .NET also does not implement Flush, it's only implemented in .NET Core.