2017-11-23 7 views
1

ServiceStackのサーバーイベント機能を使用するクロスオリジンHTTPリクエストが含まれていない場合、2つのブラウザを同期できます。それは文書化されたように簡単に動作します:ServiceStack SSEはCORSの場合にChromeでERR_INVALID_CHUNKED_ENCODINGを返します

(1)Plugins.Add(新しいServerEventsFeature());

(2)のSyncRequestエンドポイント:

[Route("/channels/{Channel}/sync", "POST")] 
    public class SyncRequest : IReturnVoid 
    { 
     public string From { get; set; } 
     public string ToUserId { get; set; } 
     public string Channel { get; set; } 
     public string Message { get; set; } 
     public string Selector { get; set; } 
    } 
    public class SyncService : Service 
    { 
     public IServerEvents ServerEvents { get; set; } 

     public void Any(SyncRequest request) 
     { 
      ServerEvents.NotifyChannel(request.Channel, "sync", request.From); 
     } 
    } 

(3)ブラウザで:これにより

var mychannel = 'example'; 
    var source= new EventSource(`${serviceUrl}/event-stream?channel={mychannel}`); 
    source.onmessage = (m) => {}; // etc. 

私は(一方のブラウザで)のSyncRequestエンドポイントを呼び出すことによって、ブラウザを同期することができ、処理他のブラウザのEventSourceから出てくるメッセージ。

しかし同期サーバーが別のドメインにあり、クロスオリジンのHTTP要求がを必要としている場合、それは失敗します。 Plugins.Add(new CorsFeature(...))はしばらく後に動作するように見えますが、Chrome(Linuxの場合)ではまずコンソールにERR_INVALID_CHUNKED_ENCODINGエラーが表示されます。

インターネットでは、Chromeが厳格なw.r.tという申し立てがあります。これにより、これらのERR_INVALID_CHUNKED_ENCODINGエラーが発生する可能性があります。私は/ event-stream呼び出しに対する応答がTransfer-Encoding:chunkedヘッダーを持っていることも確認していますが、これが本当に原因であるかどうか、またそれをどう回避するかはわかりません。そのレスポンスヘッダがTransfer-Encoding:chunkedを含める(ハートビートは、デフォルトではTransfer-Encoding:identityを持っている) -

Plugins.Add(new ServerEventsFeature { 
     OnInit = request => { 
      request.Response.AddHeader("Transfer-Encoding", "identity"); 
     }, 
     OnHeartbeatInit = request => { 
      request.Response.AddHeader("Transfer-Encoding", "identity"); 
     } 
    }); 

をが、これは/event-stream?channel=exampleコールには影響しません:another question on ServiceStack's SSE plus CORSmythz

は、応答ヘッダがそうのように変更することができることを示唆しています。

ブラウザが/event-stream?channel=exampleを使用して接続を再確立しようとしていて、初めて成功したときにEventSourceオブジェクトが動作し、ハートビートが発生し、同期が可能です。

私はServiceStack/4.512 NET45 Unix/Monoを使用しています。

問題は次のとおりです。ERR_INVALID_CHUNKED_ENCODINGエラーのないSSE接続をすぐに確立する方法はありますか?たぶんServiceStackにcommon error referred to in another questionがありますか?

答えて

1

Chunked Transfer-Encodingは、長さがわからないサーバー送信イベントの長期実行HTTP応答では正常です。 MonoのHTTP実装で問題が起きている可能性があります。Linux/OSX上で動作している場合は、代わりにrun ServiceStack on .NET Coreを推奨します。

+0

チャンネルにチューニングされた新しいブラウザでは、チャンクが間違っている可能性のあるメッセージが表示され、他のブラウザが中断されます。 複数のブラウザが同じチャンネルにチューニングされている場合、自分の足元に戻って、他の人を混乱させる可能性があり、同期要求を送受信できない。 NotifyChannelを呼び出すsync POSTリクエストは常に完璧に動作するので、希望はあります。だから何とかNotifyChannelは適切にチャンクされたメッセージを送信するのに対し、onConnectはそれをしません。確かにこれを修正する方法がなければなりません! –

+0

@AlexZubrinsky Transfer-エンコーディング応答は、フレームワークによって生成されません。要求の長さを判断できない場合、内部Webプラットフォームによって暗黙的に追加されます。この解決策は、Monoを使用して.NETコアに移行する場合です。 MonoのASP.NET実装はバグがあり、誰もそれをサポートしていません。 – mythz

+0

ありがとうございます!私たちは確かに.NETコアで終わるでしょう。 –

関連する問題