Forum Discussion
NimbostratusHTTP::payload replace with MORE data?
when HTTP_REQUEST priority 300 {
set original_payload [HTTP::payload]
set original_length [HTTP::header value Content-Length]
if { [lindex $session_var 7] == 1 and not ( [info exists all_done] ) } {
set original_request [HTTP::request]
HTTP::uri "/lookup.asp?id=[lindex $session_var 6]"
snatpool legacy-connect_snat
pool lookup.pool
event HTTP_REQUEST disable
} elseif { [info exists all_done] and $all_done == 1 } {
lset session_var 7 2
HTTP::header replace SOFTCERT_NUM $authkey
unset all_done
}
}
when HTTP_RESPONSE priority 300 {
if { [lindex $session_var 7] == 1 and not ( [info exists all_done] ) } {
HTTP::collect 1
}
}
when HTTP_RESPONSE_DATA priority 300 {
if { [lindex $session_var 7] == 1 and not ( [info exists all_done] ) } {
set authkey [HTTP::payload]
set all_done 1
event HTTP_REQUEST enable
HTTP::header replace "Content-Length" $original_length
HTTP::payload replace 0 $original_length $original_payload
HTTP::retry $original_request
}
}
(Note that a few things, like session_var, are set by another script)
The purpose of this is to intercept a request, store the payload and length (1665 bytes) to a local variable, then take certificate information, and, by replacing the URI and doing a "pool" statement, go off and look up some data on another server. Upon return, it takes the reply data (10 bytes), stuffs it into another header, then HTTP::payload replace with what was originally gathered at the beginning. It then does a HTTP::retry with the original request.
Everything seems to be working great until I go to replace the payload, then it bombs with a "list index out of range". By playing around, it seems that since my payload went from 1665 bytes down to 10 through the lookup, it won't let me replace the payload with anything more than 10 bytes.
Does anyone have any idea how I can increase the buffer size that's allocated to this new payload so that I can replace it with the original data for my http::retry?
This is my first post, and I've been looking at this until my eyes bled, so be gentle 😉
Thanks!
Tony
15 Replies
J_CastroWe are having the same issue, at this time we have two virtual servers in a layered fashion and one of them is just for adding headers in the response.
Our approach is now using Open-id, so we are seeing that F5 does not add the headers at their own responses in the oauth URLs, EJ. {fqdn}/.well-known/openid-configuration
At this time, the solution for me is changing in someway the f5 internal server (apache) to add CORS response headers at any of the responses, but I don't know how, yet.
By th way, the iRule in this case, where we are using Open-id, will not work because the HTTP::Response will trigger only if the traffic comes from the server side. In this case, the Open-id portal and Oauth services run only in the client side.
Daniel_W__13795Hi,
I solved the issue without layered VS. I't simply using HTTP_RESPONSE_RELEASE instead of HTTP_RESPONSE
when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable } when HTTP_REQUEST { unset -nocomplain cors_origin if { [HTTP::header "Origin"] contains "mydomain.com" } { set cors_origin [HTTP::header "Origin"] log local0. "CORS Origin seen: [HTTP::header "Origin"]" } } when HTTP_RESPONSE_RELEASE { 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 log local0. "CORS Header sent: Access-Control-Allow-Origin $cors_origin" } }- daren
I am trying to use this on my LTM with APM I want a single VS if possible. But this gets stuck on preflight. any ideas?
- J_Castro_190752
We are having the same issue, at this time we have two virtual servers in a layered fashion and one of them is just for adding headers in the response.
Our approach is now using Open-id, so we are seeing that F5 does not add the headers at their own responses in the oauth URLs, EJ. {fqdn}/.well-known/openid-configuration
At this time, the solution for me is changing in someway the f5 internal server (apache) to add CORS response headers at any of the responses, but I don't know how, yet.
By th way, the iRule in this case, where we are using Open-id, will not work because the HTTP::Response will trigger only if the traffic comes from the server side. In this case, the Open-id portal and Oauth services run only in the client side.
- Daniel_W__13795
Hi,
I solved the issue without layered VS. I't simply using HTTP_RESPONSE_RELEASE instead of HTTP_RESPONSE
when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable } when HTTP_REQUEST { unset -nocomplain cors_origin if { [HTTP::header "Origin"] contains "mydomain.com" } { set cors_origin [HTTP::header "Origin"] log local0. "CORS Origin seen: [HTTP::header "Origin"]" } } when HTTP_RESPONSE_RELEASE { 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 log local0. "CORS Header sent: Access-Control-Allow-Origin $cors_origin" } }
john_sergio_menTHANKS
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}
