HAproxy:OPTIONS和POST方法的不同的503错误文件 [英] HAproxy: different 503 errorfile for OPTIONS and POST methods

查看:3066
本文介绍了HAproxy:OPTIONS和POST方法的不同的503错误文件的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们有一个Web应用程序使用对在不同域( - > CORS需要)上运行的后端的Ajax调用。
后端由一个 HAproxy 1.4.22 和多个Wildfly(在OpenShift PaaS上运行)组成。如果没有Wildfly可用(例如在维护期间),HAproxy为每个请求或配置的错误文件提供503。到目前为止这么好...



这是一个问题,Web应用程序根据被拒绝的后端请求(503)正确显示维护模式,因为浏览器首先发送一个OPTIONS请求(preflight),并获得一个503。这最终导致浏览器不会将这个状态代码反映到JavaScript中执行的ajax调用(我们总是将状态代码0作为响应,因为浏览器将其解释为预检的致命失败并拒绝任何访问)。
这个故事不是新的,在stackoverflow有很多帖子。



那么如何解决这个问题呢? 我的想法是提供两个不同的错误文件(HAproxy语言中的错误文件) - 一个服务OPTIONS请求,内容为HTTP / 1.1 200 OK .... Access-Control-Allow-Origin:*。 ...在浏览器中传递预检检查,然后一个错误文件为POST请求提供内容HTTP / 1.1 503 .....,以使浏览器真正反映ajax响应中的状态503。

 全球
maxconn 256

默认值
模式http
日志全局
选项httplog
...

listen express 127.4.184.2:8080
acl is_options方法OPTIONS
acl is_post方法POST

错误文件503 /var/lib/openshift/564468c90c1e66c7f2000077/app-root/runtime/repo/503.http如果is_post
错误文件503 / var / lib / openshift / 564468c90c1e66c7f2000077 / app-root / runtime / repo / options.http if is_options

option httpchk GET /
http-check expect rstatus 2 .. | 3 .. | 401

balance leastconn
server local-gear 127.4.184.1:8080 check fall 2 rise 3 inter 2000 cookie local-564468c90c1e66c7f2000077

我理解这不能工作,因为 errorfile 不允许如果< condition> / p>

我如何实现我的愿望行为?如果有人有另一个解决方案来解决这个Maintanace模式任何想法...



提前感谢!

解决方案

发现了一个好的解决方案:




  • 定义两个后端(因此将listen部分分成frontend li>
  • 前端部分检查请求方法,并使用一个后端来回答OPTIONS请求,并使用一个后端来回答所有其他请求。

  • 第一个定义的后端用于回答所有OPTIONS请求与200:这可以用一个错误文件,如果我们不列出任何服务器在这一部分,这个后端被标记为Down,因此响应,因此错误文件

  • 第二个定义的后端保留为真实后端,并在真实服务器关闭的情况下响应(也就是我们发送200返回到OPTIONS请求)


  • 在错误文件中,我们可以添加CORS标头。





  • HAproxy.cfg

     全球
    maxconn 256

    默认值
    模式http
    日志全局
    选项httplog
    选项dontlognull
    maxconn 128
    ...
    $ b b前端平衡器
    bind 127.8.155.130:8080
    模式http
    acl is_options方法选项
    use_backend cors_backend if_options
    default_backend business_backend

    后端cors_backend
    errorfile 503 options.http

    backend business_backend
    errorfile 503 503.http
    server ...
    server ...





    options.http

      HTTP / 1.1 200 OK 
    访问控制允许标头:Origin,Accept,X-Session_id,Content-Type
    访问控制-Allow-Origin:*
    Access-Control-Allow-Credentials:true
    Access-Control-Max-Age:86400
    访问控制允许方法:HEAD,DELETE,POST, GET,OPTIONS,PUT
    连接:close
    [空行]

    br>
    503.http

      HTTP / 1.1 503服务不可用
    Cache-Control:no-cache
    Access-Control-Allow-Origin:*
    Connection:close
    [空行]

    还有一个额外的冒险:这个配置为HAproxy自动提供所有的OPTIONS请求 - 即使是CORS支持!


    We have a Web application using ajax calls to a backend running on different domain (-> CORS needed). The backend consists of a HAproxy 1.4.22 and then multiple Wildflys (running on OpenShift PaaS). In case no Wildfly is available (e.g. during "Maintenance"), HAproxy serves 503 to every request or the configured errorfile. So far so good...

    This is a problem for the Web application to properly visualise "Maintenance Mode" according to a rejected backend request (with 503), because the browser first sends an OPTIONS request (preflight) and gets already a 503 to it. This ends up that the Browser does not reflect this status code to the performed ajax call in JavaScript (we get always status code 0 as response because the browser interpret it as fatal failure of preflight and denies any access). This story is not new and there are many posts at stackoverflow.

    So how to solve this problem? My idea is to deliver two different errorfiles ("errorfile" in HAproxy language) - one serving OPTIONS requests with content "HTTP/1.1 200 OK.... Access-Control-Allow-Origin: *...." to pass the preflight check in the browser, then one errorfile serving the POST requests with content "HTTP/1.1 503 ....." to let the browser really reflect the status 503 in the ajax response. However, I am not able to get this running.

    global
        maxconn     256
    
    defaults
        mode                    http
        log                     global
        option                  httplog
        ...
    
    listen express 127.4.184.2:8080
        acl is_options method OPTIONS
        acl is_post method POST
    
        errorfile 503 /var/lib/openshift/564468c90c1e66c7f2000077/app-root/runtime/repo/503.http if is_post
        errorfile 503 /var/lib/openshift/564468c90c1e66c7f2000077/app-root/runtime/repo/options.http if is_options
    
        option httpchk GET /
        http-check expect rstatus 2..|3..|401
    
        balance leastconn
        server local-gear 127.4.184.1:8080 check fall 2 rise 3 inter 2000 cookie local-564468c90c1e66c7f2000077
    

    I understand that this cannot work because errorfile does not allow the if <condition> variant.

    How can I achieve my wished behaviour? And if someone has another solution to solve this "Maintanace Mode" / CORS problem, I am open for any idea...

    Thanks in advance!

    解决方案

    I found a good solution:

    • define two "backends" (therefore split the "listen" section into "frontend" and "backend"
    • The "frontend" section checks for the request method and uses one "backend" to answer OPTIONS request and one "backend" to answer all others.
    • The first defined "backend" is used to answer all OPTIONS requests with 200: This can be done with an errorfile and if we do not list any server in this section, this "backend" is marked as Down and responses therefore the errorfile (in which we send 200 back to the OPTIONS request).
    • The second defined "backend" stays for the "real" backend and responds - in case the real servers are down - also the content from an errorfile.
    • In the errorfiles, we can add the CORS headers.


    HAproxy.cfg:

    global
         maxconn     256
    
    defaults
        mode                    http
        log                     global
        option                  httplog
        option                  dontlognull
        maxconn                 128
        ...
    
    frontend balancer
        bind 127.8.155.130:8080
        mode http
        acl is_options method OPTIONS
        use_backend cors_backend if is_options
        default_backend business_backend
    
    backend cors_backend
        errorfile 503 options.http
    
    backend business_backend
        errorfile 503 503.http
        server ...
        server ...
    


    options.http

    HTTP/1.1 200 OK
    Access-Control-Allow-Headers: Origin, Accept, X-Session_id, Content-Type
    Access-Control-Allow-Origin: *
    Access-Control-Allow-Credentials: true
    Access-Control-Max-Age: 86400
    Access-Control-Allow-Methods: HEAD, DELETE, POST, GET, OPTIONS, PUT
    Connection: close
    [empty line]
    


    503.http

    HTTP/1.1 503 Service Unavailable
    Cache-Control: no-cache
    Access-Control-Allow-Origin: *
    Connection: close
    [empty line]
    

    There is one additional adventage: This configuration serves all OPTIONS requests autonomeously by HAproxy - even with CORS support!

    这篇关于HAproxy:OPTIONS和POST方法的不同的503错误文件的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

    查看全文
    登录 关闭
    扫码关注1秒登录
    发送“验证码”获取 | 15天全站免登陆