上下文代理预检选项请求

Context Broker Preflight OPTIONS request

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

我在启动应用程序时使用 -corsOrigin __ALL 标志在 CB 上启用了 CORS,我可以通过在 POSTMAN 中发出请求并在回应:access-control-allow-origin →*.

我需要在我的 GET 请求中指定 Fiware-Service header 以获取正确的实体,我认为这是在发出请求而不是 simple,触发 OPTIONS HTTP请求。

检查传出请求,Chrome 报告已发送这些 header:

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

我从 Context Broker 得到的响应是:

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

A ,对一个类似的问题说:

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

这是为了从请求中删除 non-standard header。但是,对我来说,我看不到任何 non-standard header 被发送。

正在读取指定允许的 header 的 Fiware documentation on Access-Control-Allow-Headers, there is a link to the source code。在那里,我可以看到 Fiware-Service header 已定义,但它不会 case-match 从浏览器发送 header(浏览器已将我的 header s 全部小写)。


有谁知道 Context Broker 中的 "the headers check" 是否是 case-sensitive?

如果不是,还有什么问题?


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

基于 the discussion on the associated github issue 看来问题是由于 Context Broker 很旧(版本 1.7.0)并且该版本尚未开发该功能。

解决方法是将Context Broker更新到最新版本(目前为2.2.0)。

谢谢@fgalan,是的,该功能包含在最新的 Context Broker 版本中。但是,我们的系统目前非常脆弱,所以在我们可以自信地重建并迁移到更新版本之前,我将使用 NGINX 模拟选项请求的 HTTP 响应。

此配置侦听不同端口上的请求到 Context Broker,并在 OPTIONS HTTP 请求到达时发送成功响应。

如果不是 OPTIONS HTTP 请求,NGINX 会将请求转发到 Context Broker 实例。

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;
    }
}