Context Broker预检选项请求 [英] Context Broker Preflight OPTIONS request

问题描述

我正在尝试从浏览器向Context Broker实例发出GET请求.

I'm trying to make a GET request to a Context Broker instance from a browser.

启动应用程序时，我已使用-corsOrigin __ALL标志在CB上启用了CORS，并且可以通过在POSTMAN中发出请求并在响应中看到此标头来看到此功能:access-control-allow-origin →*.

I've enabled CORS on the CB using the -corsOrigin __ALL flag when starting the app, and I can see that this has worked by making a request in POSTMAN and seeing this header in the response: access-control-allow-origin →*.

我需要在我的GET请求中指定Fiware-Service标头，以获取正确的实体，我相信这使得请求不是

I need to specify the Fiware-Service header in my GET request in order to get the correct entities, which I believe is making the request not simple, triggering an OPTIONS HTTP request.

Chrome检查外发请求后，报告发送了以下标头:

Inspecting the outgoing request, Chrome reports that these headers are sent:

Access-Control-Request-Headers: fiware-service
Access-Control-Request-Method: GET

我从Context Broker获得的响应是​​:

The response I get from the Context Broker is:

Request URL: http://xxx.xxx.xxx.xxx:1026/v2/entities/
Request Method: OPTIONS
Status Code: 405 Method Not Allowed

A McMutton先前的回答，它回答了类似的问题:

A previous answer by McMutton, to a similar question stated:

"对您的js代码进行必要的更改，以确保您的请求 属于简单请求的范围."

"do the necessary changes on your js code to make sure your request falls within the scope of simple requests."

直接从请求中删除非标准标头.但是，对我来说，我看不到发送任何非标准标头.

Which was directed at removing non-standard headers from the request. However, for me I cannot see any non-standard headers being sent.

阅读 Fiware关于Access-Control-Allow-Headers的文档，有指向

Reading the Fiware documentation on Access-Control-Allow-Headers, there is a link to the source code where the allowed headers are specified. There, I can see the Fiware-Service header defined, but it does not case-match the headers being sent from the browser (the browser has converted my headers to all lower case).

有人知道上下文代理中的标头检查"是否区分大小写吗?

Does anyone know if "the headers check" in the Context Broker is case-sensitive?

如果不是，那还有什么问题?

If not, what else could be the issue?

编辑:此问题似乎已在此处报告: https://github.com/telefonicaid/fiware-orion/issues/3453

Edit: this issue seems to have been reported here: https://github.com/telefonicaid/fiware-orion/issues/3453

推荐答案

感谢@fgalan，是的，该功能包含在最新的Context Broker版本中.但是，我们的系统目前非常脆弱，因此，在我们放心地重建并迁移到较新版本之前，我将使用NGINX模拟选项请求的HTTP响应.

Thanks @fgalan, yes the feature is included in the latest Context Broker version. However, our system is currently quite fragile, so until we can confidently re-build and migrate to the newer version I'm going to mock the HTTP response for the options request using NGINX.

此配置在到Context Broker的其他端口上侦听请求，并在OPTIONS HTTP请求到达时发送成功响应.

This configuration listens for requests on a different port to the Context Broker, and sends a success response when OPTIONS HTTP requests arrive.

如果不是OPTIONS HTTP请求，则NGINX会将请求转发到Context Broker实例.

If it's not an OPTIONS HTTP request, NGINX forwards the request to the Context Broker instance.

server {
    listen 1885;
    listen [::]:1885;

    location / {
        if ($request_method = OPTIONS ) {
            add_header Content-Length 0;
            add_header Content-Type text/plain;
            add_header 'Access-Control-Allow-Origin' '*';
            add_header 'Access-Control-Allow-Methods' 'GET, OPTIONS';
            add_header 'Access-Control-Allow-Headers' 'Fiware-Service';
            return 204;
        }
        proxy_pass http://xxx.xxx.xxx.xxx:1026;
        proxy_set_header Host      $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这篇关于Context Broker预检选项请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！