アヤックスのアクセスzuulの問題のためのクロスドメインソリューションにより、

使用する際に最初にバックグラウンドにおいて見出さクロスドメインリクエストzuul jqueryajaxゲートウェイは、JSONデータ受信要求を取得することができなかった、および受信応答データの背景を取得することができませんでした。ブラウザのデバッガを開き、AJAX POSTリクエストが統一オプションになっている自分自身を発見し、これはそれが起こったのかですか？

根本的な理由は、W3C仕様のような主張であります！クロスドメインの要求に、単純な要求に、複雑な要求（getおよびいくつかのポスト、ポストは、コンテンツタイプapplication / x-www-form-urlencodedで、マルチパート/フォームデータ、プレーンテキスト/の一種属する）を。複雑な要求が発行される前に、要求のオプションがあるでしょう。

オプションには、それが何を要求していますか？これは、この方法により、クライアントは、特定のリソースを要求する前に取るアクションは、リソースのために必要であるかを決定、またはサーバーのパフォーマンスを理解することができ、探索要求です。

オプションのイベントでのAjaxリクエストクロスドメインAJAXリクエスト、プローブは、また進歩で、要求がJSONであれば、それは複雑な要求であるため、先にリクエストが信頼性が高く、安全であるかどうかを確認するための要求のオプションを発行する必要があり、応答がHTTPステータス自然の中で使用可能なオプション、500 \ 403 \ 404などなどを拒否された場合、それはポストを停止し、他の問題は、要求を置きます。

以上のように、この説明によると、その後、ここで私は次のようにフィルタの定義は、コードの一部である私のzuulコードのサポートを、変更させて頂いております：

       @Override
        public Object run() throws ZuulException {
            RequestContext requestContext = RequestContext.getCurrentContext();
            String requestBody = null;
            try {
                requestBody = StreamUtils.copyToString(requestContext.getRequest().getInputStream(), Charsets.UTF_8);
            } catch (IOException e) {
                log.error("", e);
            }
    
            requestContext.addOriginResponseHeader("content-type", "application/json;charset=utf-8");
            //设置可以跨域访问
            requestContext.addZuulResponseHeader("Access-Control-Allow-Headers", "content-type,x-requested-with");
            requestContext.addZuulResponseHeader("Access-Control-Allow-Origin", "*");
            requestContext.addZuulResponseHeader("content-type", "application/json;charset=utf-8");
          // 如果为options请求则一定要返回200状态码
            if ("options".equals(requestContext.getRequest().getMethod().toLowerCase())) {
                requestContext.setSendZuulResponse(false);
                requestContext.setResponseStatusCode(HttpStatus.OK.value());
                return null;
            }
         //....省略部分代码 
        }