I am experiencing a somewhat odd situation. I created an HTTP profile and setup a name value pair in the Request Header Insert (SSL_ENV:On). When I debug in Fiddler to see if the header is inserted, I don't see anything which is really strange. So I went the iRule route and tried to test if the header was set and if it wasn't set it to On: when HTTP_REQUEST { set myhost [HTTP::host] set myuri [HTTP::uri] if { ![HTTP::header "SSL_ENV"] equals "On" } { HTTP::header insert SSL_ENV On log local0. "HEADER HTTPVS: [HTTP::header "SSL_ENV"]" } else { if { $myuri starts_with "/API" } { log local0. "URL: $myuri going to non_ssl pool" pool pool_one_80 } else { HTTP::redirect "https://$myhost$myuri" } } } It throws a strange error on the ![HTTP::header [undefined procedure: !HTTP::header] [!HTTP::header "SSL_ON"] I thought inserting a header would be really straight forward and easy, but somehow I am missing something. Thoughts? BTW: I created the same rule in SSL and HTTP to check if the header didn't exist and then create it. Still no dice.

Hi Wes, Try modifying this one line to seperate the functions: FROM: if { ![HTTP::header "SSL_ENV"] equals "On" } { TO: if { !([HTTP::header "SSL_ENV"] equals "On") } { This will allow the Header value to be found and its value determined first, then does the not compare. Hope this helps.

When I debug in Fiddler to see if the header is inserted, I don't see anything which is really strange. It's not so strange as it might look. Besides to syntax error in the iRule (see comment of Michael Yates), Fiddler is the wrong place to look for the header. Fiddler runs on the client and the iRule inserts the HTTP Request header only into requests to the backend servers. So there is no chance to see those modifications in Fiddler at the client. As soon as your iRule works, you could add the following log statement to show the whole request, including any headers: log local0. "[HTTP::request]" Simply put that at the end of HTTP_REQUEST. Regards Kurt Knochner

That makes total sense then regarding the HEADER debugging, and the code change above. The strange thing is the variable doesn't seem to remain static once set. I wonder if I have to do both on the HTTP_RESPONSE as well as REQUEST.

The strange thing is the variable doesn't seem to remain static once set. That's true, as this is just a HTTP request header. That's not "persistent" like a cookie. I wonder if I have to do both on the HTTP_RESPONSE as well as REQUEST. Why would you want to do that? The client (a browser) will not take care about any special HTTP header, even if you set it in HTTP_RESPONSE, unless you have javascript or activex code running in the browser that checks that header. In general you are inserting a certain HTTP request header to add some information to a request. This additional information will be used by the backend application to perform additional operations if that information is present. Based on the name of your header I assume you want to tell the backend application if the original request has been encrypted or not. This will have a meaning for the backend application but not for the client. Hope that helps. Regards Kurt Knochner

Make sense, yes the header is telling the backend servers to maintain a secure session, we recently moved to F5 from a different vendor and it would appear that the header variable (ASP server variable) may be displayed differently. The team is checking using something like the following: if Request.ServerVariables("SSL_ENV")="On" then When I dump the REQUEST in the iRule I see the following: SSL_ENV: On It appears F5 is appending the variable with a :, but if I check the value on the F5 in an iRule (e.g., if it exists), the boolean will return true if I specify variable = "On", but the code doesn't see that. Not sure if the : is the culprit or what. Regarding the RESPONSE yes you are correct, there is no client side work going on, this is all on the backend for each request that comes through.

Header Inserts | DevCentral

20 Replies

Michael_Yates
Nimbostratus
Nov 08, 2011
Hi Wes,

Try modifying this one line to seperate the functions:

FROM: if { ![HTTP::header "SSL_ENV"] equals "On" } { TO: if { !([HTTP::header "SSL_ENV"] equals "On") } {

This will allow the Header value to be found and its value determined first, then does the not compare.

Hope this helps.
Kurt_Knochner_5
Cirrus
Nov 08, 2011
When I debug in Fiddler to see if the header is inserted, I don't see anything which is really strange.

It's not so strange as it might look. Besides to syntax error in the iRule (see comment of Michael Yates), Fiddler is the wrong place to look for the header. Fiddler runs on the client and the iRule inserts the HTTP Request header only into requests to the backend servers. So there is no chance to see those modifications in Fiddler at the client. As soon as your iRule works, you could add the following log statement to show the whole request, including any headers:

log local0. "[HTTP::request]"

Simply put that at the end of HTTP_REQUEST.

Regards

Kurt Knochner
Wes_98712
Nimbostratus
Nov 08, 2011
That makes total sense then regarding the HEADER debugging, and the code change above. The strange thing is the variable doesn't seem to remain static once set. I wonder if I have to do both on the HTTP_RESPONSE as well as REQUEST.
Kurt_Knochner_5
Cirrus
Nov 08, 2011
The strange thing is the variable doesn't seem to remain static once set.

That's true, as this is just a HTTP request header. That's not "persistent" like a cookie.

I wonder if I have to do both on the HTTP_RESPONSE as well as REQUEST.

Why would you want to do that? The client (a browser) will not take care about any special HTTP header, even if you set it in HTTP_RESPONSE, unless you have javascript or activex code running in the browser that checks that header.

In general you are inserting a certain HTTP request header to add some information to a request. This additional information will be used by the backend application to perform additional operations if that information is present. Based on the name of your header I assume you want to tell the backend application if the original request has been encrypted or not. This will have a meaning for the backend application but not for the client.

Hope that helps.

Regards

Kurt Knochner
Wes_98712
Nimbostratus
Nov 09, 2011
Make sense, yes the header is telling the backend servers to maintain a secure session, we recently moved to F5 from a different vendor and it would appear that the header variable (ASP server variable) may be displayed differently. The team is checking using something like the following:

if Request.ServerVariables("SSL_ENV")="On" then

When I dump the REQUEST in the iRule I see the following:

SSL_ENV: On

It appears F5 is appending the variable with a :, but if I check the value on the F5 in an iRule (e.g., if it exists), the boolean will return true if I specify variable = "On", but the code doesn't see that. Not sure if the : is the culprit or what.

Regarding the RESPONSE yes you are correct, there is no client side work going on, this is all on the backend for each request that comes through.
Kurt_Knochner_5
Cirrus
Nov 09, 2011
It appears F5 is appending the variable with a :,

That's correct, as it's the syntax for a HTTP header.

name: value

BTW: it's not a variable, but a HTTP request header.

Regarding your ASP code. I believe the correct way to access the HTTP request header is HTTP_name_of_header, in your case HTTP_SSL_ENV, instead of SSL_ENV.

See also here: http://www.w3schools.com/asp/coll_servervariables.asp

Regards

Kurt Knochner
nitass
Employee
Nov 09, 2011
Regarding your ASP code. I believe the correct way to access the HTTP request header is HTTP_, in your case HTTP_SSL_ENV, instead of SSL_ENV.i agree with Kurt.

this is another article.

accessing http headers and environment variables

http://www.4guysfromrolla.com/webtech/111099-1.shtml
Kurt_Knochner_5
Cirrus
Nov 09, 2011
we recently moved to F5 from a different vendor

btw. what's that vendor?

Regards

Kurt Knochner
Wes_98712
Nimbostratus
Nov 09, 2011
Kurt/Nitass,

Excellent response, thanks a lot for clarifying. I'll forward on the URLs to the dev team for review, I saw the same articles but noticed that using the other load balancer the same code in place today worked, so it appears F5 (as it should be) adheres more towards industry standards -- good thing. I think this is the source of our issues making sure they reference the header value correctly, I am going to ask them to test both with header_value: and http_header_value and see what works, I'll post the responses tomorrow.

One last question regarding HTTP_REQUEST vs HTTP_REQUEST_SEND, implementing the insert should be within the initial REQUEST correct? No reason to switch to the REQUEST_SEND correct?
nitass
Employee
Nov 09, 2011
One last question regarding HTTP_REQUEST vs HTTP_REQUEST_SEND, implementing the insert should be within the initial REQUEST correct? No reason to switch to the REQUEST_SEND correct?since you do not need any information from server-side, inserting it in client-side event i.e HTTP_REQUEST is fine.