Forum Discussion
Adding CORS response headers
- 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.
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_Sep 09, 2015CirrusHmmm. 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.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com