Forum Discussion

Cirrus

Jul 10, 2015

Solved

Adding CORS response headers

Hey all, There are a number of other older (2013-era) threads about CORS headers, and I want to ask a specific question which has not been asked there: Can I add a response header using HTTP:...

Oct 08, 2015

To anyone who comes in afterwards and wants to find a 'final' solution, here's what we ended up with (which functions perfectly, at least for us):

when HTTP_REQUEST priority 200 {
    unset cors_origin -nocomplain
    if { [HTTP::header Origin] ends_with ".example.com" } {
        if { ( [HTTP::method] equals "OPTIONS" ) and ( [HTTP::header exists "Access-Control-Request-Method"] ) } {
             CORS preflight request - return response immediately
            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"
        } else {
             CORS GET/POST requests - set cors_origin variable
            set cors_origin [HTTP::header "Origin"]
        }
    }
    ...
    ...
    ...
    other irules
    ...
    ...
    ...
}
when HTTP_RESPONSE {
     CORS GET/POST response - check cors_origin variable set in request
    if { [info exists cors_origin] } {
        HTTP::header insert "Access-Control-Allow-Origin" $cors_origin
        HTTP::header insert "Access-Control-Allow-Credentials" "true"
        HTTP::header insert "Vary" "Origin"
    }
}

If you have any comments about this, please do so. And, of course, feel free to use it yourself.

IheartF5_45022

Nacreous

Sep 08, 2015

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

Rory_Hewitt_F5_
Cirrus
Sep 09, 2015
Hmmm. When I compare yours with mine, I see that you're using 'eq' and '&&' rather than 'equals' and 'and', but those function exactly the same, don't they? Also I can see that you're not using all the additional parentheses around each sub-clause, but that SEEMS like a stylistic thing, right? The only DIFFERENCE is that you're not putting the header names in quotes, but you ARE including the entire value for each header in double-quotes. but again, shouldn't my version also work? Isn't this: HTTP::respond 200 Access-Control-Allow-Origin "[HTTP::header Origin]" the same as this: HTTP::respond 200 Access-Control-Allow-Origin [HTTP::header "Origin"] I REALLY appreciate your help, but the team that actually deploys these iRules to our environments won't accept a new version from me, and I guess I'm still not clear on what's actually WRONG with my version - where exactly is my error? The XML file I'm talking about is the BigIpConfiguration file.