2017-02-14 18 views
2

XmlHttpRequestとのクロスオリジンの問題を避けるために、Fetch APIを使用してXMLデータのPOSTを処理しようとしています。私が直面している問題は、自分のContent-Typeを 'text/xml'(この場合唯一サポートされているcontent-typeヘッダー)に設定しても、リクエストのcontent-typeがtext/plainにリセットされてHTTPステータスが415を要求されたコンテンツから取得する。Fetch APIを使用してPOST XMLを使用する

function doFetch(Content) 
    { 
     return fetch(
     URL, { method: 'POST', 
      mode: 'no-cors', 
      headers: new Headers(
      {'Content-Type': 'text/xml; charset=utf-8', 
      'Accept': '*/*', 
      'Accept-Language': 'en-GB', 
      'Accept-Encoding': 'gzip, deflate', 
      'Connection': 'Keep-alive', 
      'Content-Length': Content.length     
      }), 
      body: Content 
      }); 
    } 

コンテンツは、XMLデータの文字列です:

は、ここに私のフェッチ機能です。

そして、これは実際に使用されているヘッダである:

Content-Length:1537 
    content-type:text/plain;charset=UTF-8 

ただ、私がやろうとしていることは可能であるか疑問に思って、それは私が間違ってやっているものですか? (私はWeb開発の新しさ)。

ありがとうございます!

答えて

2

(理由は?...)を設定しているため、ブラウザではCORS-safelisted request-headers以外のリクエストヘッダーは設定できません。 the spec requirementsを参照してください:

...ガードは "request-no-cors" と/CORS-safelisted request-header、リターンではありませんであれば。

設定Content-Type: text/xml; charset=utf-8は、もはやCORSセーフリストの要求ヘッダーになりません。 Content-Typeは、その値がapplication/x-www-form-urlencoded,multipart/form-data、またはtext/plainの場合にのみ、CORSで保護された要求ヘッダーです。

ここでの解決策の開始点は、mode: 'no-cors'を使用しないことです。

mode: 'no-cors'を設定することが通常唯一正しいケースは、mode: 'no-cors'要求のためにスクリプトが応答のプロパティにアクセスできないため、レスポンスをキャッシングするためにサービスワーカーを使用している場合です。あなたがそれをキャッシュすることができる有用なこと。

私はXmlHttpRequestとのクロスオリジンの問題を避けるために、Fetch APIを使用してXMLデータのPOSTを処理しようとしています。

APIを取得するには、XHRと同じクロスオリジン・リクエスト・モデルを、次ので、それはあなたが

+0

ああはあなたに感謝...取得APIを使用して避けるようにしようとするだろうどのようなクロスオリジンの問題不明です。なぜそれが変更されているのですか?クロスオリジンの問題は、私がアクセスしようとしているリソースにOPTIONSリクエストを処理する方法がないことです。何らかの理由でInternet Explorer 11以前を使用しても、私は問題なしで送受信できますが、Edge、ChromeなどのブラウザはCORSの問題のためHTTP 404応答を提供しています。 – Krisisonfire

関連する問題