2016-05-25 3 views
1

私はMeteor 1.2アプリケーションをサーバー上で実行しています(nginxをプロキシとして使用しています)、これはさまざまな理由でDDPをサポートしていません。この場合、アプリはXHRポーリングに戻り、期待どおりに動作します。また、環境変数DISABLE_WEBSOCKETS=1でライブをデプロイして、ウェブソケットを無効にすることもできます。これはChromeのネットワークタブで確認できます。XHRはいつGET要求に戻りますか?

私は再現できない散発的な問題のバグレポートを受け取りました。

フォーム提出でPOSTを使用せず、GETに戻す(つまり、URL内のすべてのフォームデータを見ることができる)ように見え、フォームがまったく送信しないようです。

MeteorのXHRはPOSTからGETに復帰できますか?残念ながら、私はこれを再現することはできませんし、問題を示唆するログには何も見ていません。

+0

フォームはどのように提出しますか?あなたはそのコードを共有できますか? –

+0

xhrにjQueryを使用していますか?その場合、ユーザーがフォームを送信するときに$ .postを使用しますか? @christianFritzのように、フォームのhtmlコードとsubmit/postを管理するjsが必要です。 – Rebolon

+0

@ChristianFritz MeteorJSのAutoFormです.Meteorと同じように、フレームワーク自体が扱う場合はコンポーネント間の配管もあります。意味のあるコードを抽出できるかどうかがわかります。 – mpdonadio

答えて

0

失敗したフォーム要求の実際のヘッダーを表示しているようには見えません。おそらく、要求がGETであると仮定している可能性があります。私が間違っているなら、私を修正してください。ヘッダーが見えない場合は、POSTとGETを区別するカスタムロギングを追加して、実際にGETであることを明確にすることができます。

私は投稿が何とか失敗していると思いますが、エラーキャッチがありません。フォームの投稿を処理するサーバー上のロジックに行き、try catchブログをいくつか作成してカスタムロギングを行います。サーバー側が見つからないというエラーが表示される可能性があります。さらに、データベースでログが有効になっていることを確認してください。データベースに欠落している可能性があるエラーが発生している可能性があります。これがうまくいかない場合は、少なくとも、より良いエラー監視設定があります!

+0

私はこれがGETでありPOSTではないと仮定しているので、URLを通して渡されるすべてのフォームパラメータを参照していますが、実際のヘッダを見ていないということは間違いありません。私は問題を再現することができないため、これをデバッグするのは難しいです。私はまた、質問には賞金があり、これは賞金の後に追加されたので、これをダウン投票しています。これは、自動賞のための良い答えだとは思わないです。 – mpdonadio

+0

。適切なデバッグメカニズムがないとデバッグが難しい場合があります。これが私の推奨がいくつかの例外キャッチブロックを追加し、データベースのログを監視して、例外が原因で問題が発生していないことを確認することでした。 MeteorがPOSTとGETを送信する基準は、実際にPOSTであることが分かっている場合に限られます。あなたはあなたが偽りの道をあなたを送っていると仮定していると言った。 – wayofthefuture

関連する問題