Adding CORS response headers

The solution depends on where you want the traffic to go. If you want it to go to the client, then it's in the response event. To the server then it's in the request event. The HTTP::respond command is a little unique here because it forces a preemptive response to the client from a request event - in other words the server never sees the request. The iTule preemptively sends a response.

If you want to send additional data to the client based on something they said in the request, then the best approach is to set a variable in the request and look for that variable in the response event.

Hi,

We have a requirement to restrict CORS requests to domains owned by our company, or by subsidaries/partners. This rule works well for us;-

when HTTP_REQUEST {

    set debug 0
    set Origin ""

     Can be used in prod for debugging on a per-connection basis, using a browser add-on like Firebug to add the headers
    if {[HTTP::header exists "X-tls-debug"]} {
        set debug 1
    }

     log prefix for connection/request tracking. All debug logs will start with [xxxx.yyyy] where xxxx is the connection and yyyy is the request id
    if {$debug} {   
         per request identifier
        set prefix "\[[TCP::client_port].[expr {int (rand() * 100000)}]\] " 
    }

    if {[HTTP::header exists Origin]} {
         This is a cross-origin request
        if {$debug} {log local0. "${prefix} Origin:[HTTP::header Origin]"}
        switch -glob -- [HTTP::header Origin] {
            "*company.com" -
            "*company.com.au" -
            "*partner.com" -
            "*partner2.com.au" {
                 This is  a valid Origin
                switch -- [HTTP::method] {
                    "OPTIONS" {
                        if {$debug} {log local0. "${prefix} Responding to Preflight request"}
                        HTTP::respond 200 noserver  Allow "GET,HEAD,POST,OPTIONS" \
                                                    Access-Control-Allow-Origin "[HTTP::header Origin]" \
                                                    Access-Control-Allow-Methods "GET,POST" \
                                                    Access-Control-Max-Age "86400"
                        return
                    }
                    "GET" -
                    "POST" {
                        if {$debug} {log local0. "${prefix} Origin:[HTTP::header Origin]"}
                         Set variable to add headers to response
                        set Origin [HTTP::header Origin]
                    }
                }
            }
            default {
                 This is a cross-origin request,  however it's not from the correct domain
                if {[HTTP::method] eq "OPTIONS"} {
                    if {$debug} {log local0. "${prefix} Responding to OPTIONS method"}
                    HTTP::respond 200 noserver Allow "GET,POST,HEAD,OPTIONS"
                    return
                }
                 So what if it's not from correct domain,  but is GET/POST - still gonna send a response,  just not add in any CORS headers,  which will make response fail at browser
            }
        }
    }   
}
when HTTP_RESPONSE {

    if {$Origin ne ""} {
         This response needs CORS headers inserted     
       HTTP::header insert "Access-Control-Allow-Origin" $Origin
       HTTP::header insert "Access-Control-Allow-Methods" "GET,POST"
       HTTP::header insert "Access-Control-Max-Age" "86400"
       HTTP::header insert "Allow" "GET,HEAD,POST,OPTIONS"
    }

     Don't forget this - if a request is CORS-enabled,  you ALWAYS need to instruct a cache to Vary a response based on Origin,
     even if this particular request was not a valid cross-origin request. 
    HTTP::header insert "Vary" "Origin"
}

I am now having a separate problem related to a new version of sample code above. Here's the problem fragment:

if { ( [HTTP::method] equals "OPTIONS" ) and ( [HTTP::host] contains "example.com"] ) and ( [HTTP::header] exists "Access-Control-Request-Method") } {
    HTTP::respond 200 "Access-Control-Allow-Origin" "[HTTP::header Origin]" "Access-Control-Allow-Methods" "POST, GET, OPTIONS" "Access-Control-Allow-Headers" "[HTTP::header Access-Control-Request-Headers]" "Access-Control-Max-Age" "86400"        
} elseif { ( [HTTP::host] contains "example.com"] ) and ( [HTTP::header] exists "Origin") } {
     CORS GET/POST requests - set cors_origin variable
    set cors_origin [HTTP::header Origin]
}

As you can see, each of the CORS response header names in the second line is enclosed in double-quotes, so the iRule treats them as strings.

However, when I try to deploy the iRule that contains this fragment, it fails, and I'm not sure why.

Could the problem be this bit:

"Access-Control-Allow-Headers" "[HTTP::header Access-Control-Request-Headers]"

Could Tcl think that Access-Control-Request-Headers is not a string? If so, what's the solution? Can I have a string within a string?

Just try removing the quotes from all the header names as you did in your original post.

Are you sure that there is a request header Access-Control-Request-Headers in the request? Also when you say it's not working is the F5 refusing to save the iRule, or are you getting a TCL error when you execute, or is the client browser not liking the response to the OPTIONS request?

Also as a general comment be careful of intermediate downstream caches for GET requests. If the response is cacheable, and made over HTTP, then you either need to make it not cacheable OR insert "Vary:Origin".

OK I see what you've done - a few syntax issues. Not sure what you are referring to when you talk about XML/TXT files, but I recommend that you get yourself a VE lab license and run a VE instance on your computer to at least syntax check a rule before deploying it.

Note that you must ensure that you do not execute any other commands after your HTTP::respond, and especially if you are combining iRules, it's best practice to add an explicit "return" afterwards.

if { [HTTP::method] eq "OPTIONS" && [HTTP::host] contains "example.com"  && [HTTP::header exists "Access-Control-Request-Method"] } {
        HTTP::respond 200 Access-Control-Allow-Origin "[HTTP::header Origin]" Access-Control-Allow-Methods "POST, GET, OPTIONS" Access-Control-Allow-Headers "[HTTP::header Access-Control-Request-Headers]" Access-Control-Max-Age "86400"
        return
    } elseif { [HTTP::host] contains "example.com"  &&  [HTTP::header exists "Origin"] } {
         CORS GET/POST requests - set cors_origin variable
        set cors_origin [HTTP::header Origin]
}