Forum Discussion
richard_77048
Nimbostratus
Nimbostratuscookie not getting set using HTTP::cookie
Greetings,
I have a rule that is setting a cookie in an HTTP_REQUEST event before handing the request to the server. This is working on my development unit but the cookie fails to set on my production unit.
There are a couple of differences between development and production. Development is a BigIP 1500 running 9.4.7. Production is a BigIP 1600 9.4.8.
Here is what my rule is doing:
when HTTP_REQUEST {
if { not ( [HTTP::cookie language] equals $user_selected_language ) } {
HTTP::cookie language $user_selected_language
HTTP::cookie update_language 1
}
}
Again, this is working on 9.4.7 but fails to set the cookie "language" on 9.4.8. I have added logging lines to my rule and have verified that the $user_selected_language has some value in every case (so I left that part of the rule out). I tried checking for the existence of the cookie and doing an HTTP::cookie insert name "language" value "$user_selected_language" if the cookie didn't exists. That didn't do anything. If it is any help, the cookie doesn't exist.
I read through the 9.4.8 release notes and found something about a trailing semicolon getting inserted by the HTTP::cookie insert command. I didn't think that was happening in my case but I tried the workaround detailed in the release notes but that didn't help.
Any ideas? Any ideas of what to try next?
Richard
richard_77048Well, doing a little more reading and it looks like the semicolon insertion was an issue since 9.4.1. I guess that isn't likely to be the source of my problem since things work on 9.4.7.
Richard- The_BhattmanHi Richard,
I know this won't help much - BUT I had the same issue when there was one unit on version v9.4.8. Unfortunately it went away when my group decided to move away from 9.4.x entirely on either settle on 9.3.x or 10.x.
thanks,
Bhattman - richard_77048Well, it does help in that I don't feel like I am going insane now that I know that someone else has seen this.
A upgrade to v10 is in the plan but not before I have to put my rules into production.
Richard - The_BhattmanHi Richard,
What about removing the cookie and re-inserting it?
Bhattman
try this:
when HTTP_REQUEST {
if { not ( [HTTP::cookie language] equals $user_selected_language ) } {
HTTP::cookie value language $user_selected_language
HTTP::cookie value update_language 1
}
}
when HTTP_REQUEST priority 500 {
log local0. "Language: [HTTP::cookie language] - [HTTP::cookie language_update]"
}- richard_77048Bhattman,
I didn't try removing and re-inserting because the cookie wasn't there to begin with. That would be easy to try though, so, I might do that tomorrow.
John,
I did add logging to my rule, which is how I verified that the cookie was not getting set. Does doing the logging in another HTTP_REQUEST event gain me anything? I did my logging within the same event as I was attempting to set the cookie in. Does it make a difference?
Thanks,
Richard - Yes, changing the event makes a difference, although i am not sure which version this behavior starts with. It is in 10.x for sure.
Within an Event, command results are cached. It could be that the cookie is set, but the [HTTP::cookie] command is returning a cached value.
By changing events you flush the cached values and fetch the real results.
If the cookie is does not exist, you can try:
HTTP::cookie insert name Language value $user_selected_language
HTH - richard_77048Ah, I didn't kow about command result caching. Definitely good to know. I will give that a try and see if the behavior is in v9.4.x.
Thanks.
Richard - hoolio
Cirrostratus
Bypassing caching of HTTP:: commands with different priorities has worked in all iRule versions. I think you'll need to change it from priority 500 to something over 500 as the implicit priority is 500 and you can't have two events of the same priority.
Aaron - richard_77048Thanks for all the good tips. I now have a better idea of what is happening here.
So, I have ditched, at least temporarily, the approach of just sending the cookie to the server on the back. Instead, I set a cookie in an HTTP_RESPONSE event. Now, the browser reports the cookie as expected and sends it along. The F5 reports the existence and value of the cookie as expected.
Now, looking at the application logs the cookie that the application sees is this, for example: ", language=fr". That is "comma space langugae=fr". I am thoughtlessly removing the cookie and inserting it with the appropriate value. Where are the comma and the space coming from? Is this just a problem in the application? Is the F5 inserting the cookie like that? As I said earlier in this thread, there is a known issue detailed in the release notes for 9.4.x where a trailing semicolon gets inserted with a cookie. Could this be a similar issue?
Richard
