2017-11-22 8 views
0

localhost上で実行されているサーバ(つまり/のディレクトリリスト)からリソースを取得しようとするファイルシステムから静的ページを開きます。ブラウザがこの要求を転送することを拒否し、提案する:'no-cors'モードでリソースを取得すると、body-parserが失敗するのはなぜですか?

If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

それから私は、「は、CORS」を使用していないリクエストを送信:サーバー側で

let body=JSON.stringify({action:"listfiles",path:"/"}) 

let headers = new Headers() 
headers.append("Content-Type", "application/json");    

fetch('http://localhost:9000/ajax',{ 
    method: 'POST', 
    headers: headers, 
    body: body, 
    mode: 'no-cors' 
}).then(
    response=>response.json() 
).then(
    data=>this.onload(data) 
) 

私は次のように急行を使用します。

app.use('/ajax',bodyParser.json()) 

app.post("/ajax",function(req,res){  
    let action=req.body.action 
    console.log(`ajax ${action}`) 
} 

ブラウザが通じリクエストをすることができ、さらにはapp.postがちょうどリクエストボディがcorreを解析されず、要求を取得し、この時間ctlyの代わりに'listfiles'actionの値はundefinedです。 (localhostからページをロードしても同じ問題は発生しません)。

+0

https://stackoverflow.com/questions/42254685/text-response-is-empty-when-using-fetch/42255007#42255007およびhttps://stackoverflow.com/questions/43317967/handle-response-構文エラー - 予期しない入力の終わり/ 43319482#43319482基本的には、 "mode: 'no-cors'"を使用することは決してありません。フロントエンドJavaScriptが応答本体とヘッダーにアクセスするのを完全にブロックするようブラウザに指示します。 – sideshowbarker

答えて

1

クロスオリジンコール(プロトコルfile:はプロトコルhttp:と同じではありません)を作成しようとしているためです。同じオリジンプロトコルは、ブラウザによって実行されるため、サーバーが要求を認識するのは驚くことではありません。要求には、ブラウザがコードに応答を与えるためのCORSヘッダーが含まれていないため、要求には含まれません。とにかくCORSを無効にしました。 https://developer.mozilla.org/en-US/docs/Web/HTTP/CORSから

+0

私の問題は、私の要求がプリフライトを引き起こすことだと思います。私のリクエストには 'application/json' Content-Typeヘッダーが含まれているため、body-parserはjsonを解析します。許可されたヘッダーのみを含む場合、特にContent-Typeヘッダー(それ自体が許可ヘッダー)を含む場合、単純なGET、HEAD、POST要求はプリフライトをトリガーしません。許可される値はapplication/x-www-form-urlencoded、 multipart/form-dataとtext/plainを要求のためにシンプルなものにする。 – sbtpr

+1

@sbtpr:いいえ、プリフライトを起動しなかったとしても、実際のP​​OSTレスポンスに関連するヘッダーを設定することが期待されます。 (プレフライトがある場合は**両方の**応答が必要です。そうでなければ、GET/POST/HEAD応答のみ)。 –

0

は「クロスオリジンリソースは、サーバーは、Webブラウザを使用して、その情報を読み取ることが許可されているの起源のセットを記述することができ、新たなHTTPヘッダを追加することにより、標準の作品を共有また、。サーバーのデータに悪影響を及ぼす可能性のあるHTTPリクエストメソッド(特にGET以外のHTTPメソッドや特定のMIMEタイプを使用するPOST使用)の場合、ブラウザは要求を「プリフライト」し、サポートされているメソッドをサーバーからHTTP OPTIONS要求メソッドを使用し、実際のHTTP要求メソッドを使用して実際の要求を送信するサーバーからの「承認」を受け取ります。

私の要求の問題は、それが単純ではないということです。これは、body-parserミドルウェアがドキュメント本体をjsonとしてパーズするために、Content-Type: application/jsonヘッダーが含まれているためです。したがって、プリフライト要求がトリガされます。

「シンプルリクエスト

いくつかの要求がCORSのプリフライトをトリガしません。これらが呼び出され、 『(CORSを定義する)フェッチ仕様は、その用語を使用しませんが、この記事では、単純な要求』。 CORSプリフライトいわゆる「単純な要求」をトリガしない要求は、次のすべての条件を満たしている1 -is:... "ここに記載されている

条件は、メソッド、ヘッダ上の制限が含まれ設定することができます。詳しくは、docを見てください。

I、使用方法(POST)はContent-Typeヘッダを設定することも、単純な要求で許可され、一方は、単純な要求のために許可され、Content-Typeのための唯一の可能な値は

application/x-www-form-urlencoded 
multipart/form-data 
text/plain 

のためであります単純な資格を求める要求。

私のサーバーはプリフライトリクエストを知らないので、リクエストが正しく処理できないのは当然です。

期待どおりに動作するように要求をクライアントとサーバー側に渡す必要がある追加のヘッダーについては、解説を参照してください。

+1

注[こちら](https://stackoverflow.com/questions/47436830/)を参照してください。なぜ、body-parser-fail-when-i-fetch-the-no-cors-mode/47436936?noredirect = 1#comment81835710_47436936);要求が単純ではないという事実は、CORSなしでは機能しない唯一の理由ではありません。 –

+0

さて、わかりました。私が実際にリクエストをサーバに転送することができたら、私はまだ余分なヘッダが必要です。私は、これがOrigin(Referer?)であり、Access Control-Allow-Originの応答であると考えています。 – sbtpr

+0

はい。 (Refererではなく、Origin)少なくとも 'Access-Control-Allow-Headers'が必要です。 –

関連する問題