v10 cookie insert problem

Hi Jason,

 

 

Which version of 10 are you running?

 

 

Are you seeing LTM insert a comma, plus sign, semi-colon and then the new cookie name and value?

 

 

Can you test this using curl from the command line of LTM directly to the VIP and post the anonymized output?

 

 

For HTTP, you can use:

 

 

curl -v http://1.1.1.1/path/to/file.ext

 

 

For HTTPS, you can use:

 

 

curl -vk https://1.1.1.1/path/to/file.ext

 

 

If you need to insert a Host header that's not set to the IP address, you can append -H "Host: myhost.example.com" to the end of either command.

 

 

Thanks,

 

Aaron

We are running 10.0.1 build 283.0

 

 

Yes, that is exactly what is happening.

 

 

I'm adding the cookie on the HTTP_REQUEST side so I don't see it coming back on the curl response, but looking in the IIS log...the cookie is there clean, but it's the only cookie. Any request coming throuh with existing cookies is when I see the comma.

 

 

The request is coming from an application framework...the request is to a component hosted on a web server behind a VIP.

Where are you actually seeing the corrupted cookies? Is this on the server in the logs? If so, could you confirm this is what LTM sends by running a tcpdump on LTM?

I don't see this happening on a 10.0.1HF2 unit using a simple iRule to insert a cookie with or without an = in the value.

 
 when HTTP_REQUEST { 
  
    HTTP::cookie insert name rule_cookie1 value rule=value=1 
    log local0. "\[HTTP::cookie value rule_cookie1\]: [HTTP::cookie value rule_cookie1]" 
    log local0. "\[HTTP::header values Cookie\]: [HTTP::header values Cookie]" 
    log local0. "\[HTTP::header value Cookie\]: [HTTP::header value Cookie]" 
 } 
 

tcpdump showing two Cookie headers in the request send to the pool member.

tcpdump -ni 0.0 -Xs0 host 10.41.0.21

22:01:41.692897 802.1Q vlan4093 P0 10.41.1.2.36480 > 10.41.0.21.http: P 1:229(228) ack 1 win 4380 (DF) out slot1/tmm0 lis=hooleya_https_vs

0x0000 0ffd 0800 4500 010c 058d 4000 ff06 5ff6 ....E.....@..._.

0x0010 0a29 0102 0a29 0015 8e80 0050 e4a4 01b6 .)...).....P....

0x0020 575e 32ad 5018 111c 46bb 0000 4845 4144 W^2.P...F...HEAD

0x0030 202f 2048 5454 502f 312e 310d 0a55 7365 ./.HTTP/1.1..Use

0x0040 722d 4167 656e 743a 2063 7572 6c2f 372e r-Agent:.curl/7.

0x0050 3139 2e36 2028 6936 3836 2d70 632d 6379 19.6.(i686-pc-cy

0x0060 6777 696e 2920 6c69 6263 7572 6c2f 372e gwin).libcurl/7.

0x0070 3139 2e36 204f 7065 6e53 534c 2f30 2e39 19.6.OpenSSL/0.9

0x0080 2e38 6c20 7a6c 6962 2f31 2e32 2e33 206c .8l.zlib/1.2.3.l

0x0090 6962 6964 6e2f 312e 3135 206c 6962 7373 ibidn/1.15.libss

0x00a0 6832 2f31 2e32 0d0a 486f 7374 3a20 3130 h2/1.2..Host:.10

0x00b0 2e34 322e 322e 3130 320d 0a41 6363 6570 .42.2.102..Accep

0x00c0 743a 202a 2f2a 0d0a 436f 6f6b 6965 3a20 t:.*/*..Cookie:.

 

0x00d0 636c 6965 6e74 5f73 656e 743d 636c 6965 client_sent=clie

 

0x00e0 6e74 5f76 616c 7565 0d0a 436f 6f6b 6965 nt_value..Cookie

 

0x00f0 3a20 7275 6c65 5f63 6f6f 6b69 6531 3d72 :.rule_cookie1=r

 

0x0100 756c 653d 7661 6c75 653d 313b 0d0a 0d0a ule=value=1;....

0x0110 0114 0000 0000 686f 6f6c 6579 615f 6874 ......hooleya_ht

0x0120 7470 735f 7673 tps_vs

This section shows the two Cookie headers. There is a space between Cookie: and client_sent (which is the name of a cookie I had the client send), then the = and client set cookie value. Then a carriage return and line feed to separate this cookie header from the next. On the next cookie line, there is the Cookie header name, a colon, space the cookie name set in the iRule, equals, the cookie value, a semi-colon and a pair of carriage return / line feeds to end the HTTP request.

 
 0x00c0   743a 202a 2f2a 0d0a 436f 6f6b 6965 3a20        t:.*/*..Cookie:. 
 0x00d0   636c 6965 6e74 5f73 656e 743d 636c 6965        client_sent=clie 
 0x00e0   6e74 5f76 616c 7565 0d0a 436f 6f6b 6965        nt_value..Cookie 
 0x00f0   3a20 7275 6c65 5f63 6f6f 6b69 6531 3d72        :.rule_cookie1=r 
 0x0100   756c 653d 7661 6c75 653d 313b 0d0a 0d0a        ule=value=1;.... 
 

Aaron

This is what I see on the wire to the web server coming from LTM:

 

 

GET /HPOEWB.WEB/HPOEWBTestPage.aspx?tfThomletId=3761 HTTP/1.1

 

Accept: */*

 

Accept-Language: en-us

 

UA-CPU: x86

 

Accept-Encoding: gzip, deflate

 

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; GTB6.3; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2; MS-RTC LM 8; OfficeLiveConnector.1.4; OfficeLivePatch.1.3)

 

Host: host.com

 

Connection: Keep-Alive

 

Cookie: TF_SESSION=Z1NBCMSse/6Cm5P5w5eaGnxgtaCFRAhr05x5fp6Tt07GQOYozs3rI1tgDKooBNYzkhLfJQH39wVm+4MMkN3//PDS3hsxOV2rc865N09gwQJplextFRyPbhiGvn3RO+Y5Eun13hkcm6Yj9jfZBGc8qUbVJ777IhEh1JopBp6/UpHXUxCfoZTRdG9wJfkHUCAcfjDs8wdOU3Oi1weMPMp7l3v9Aq+ElGDXhpHkzMT4QXQ=; X-WE-SessionId=Z1NBCMSse/6Cm5P5w5eaGnxgtaCFRAhr05x5fp6Tt07GQOYozs3rI1tgDKooBNYzkhLfJQH39wVm+4MMkN3//PDS3hsxOV2rc865N09gwQJplextFRyPbhiGvn3RO+Y5Eun13hkcm6Yj9jfZBGc8qUbVJ777IhEh1JopBp6/UpHXUxCfoZTRdG9wJfkHUCAcfjDs8wdOU3Oi1weMPMp7l3v9Aq+ElGDXhpHkzMT4QXQ=; TFSessionId=Z1NBCMSse/6Cm5P5w5eaGnxgtaCFRAhr05x5fp6Tt07GQOYozs3rI1tgDKooBNYzkhLfJQH39wVm+4MMkN3//PDS3hsxOV2rc865N09gwQJplextFRyPbhiGvn3RO+Y5Eun13hkcm6Yj9jfZBGc8qUbVJ777IhEh1JopBp6/UpHXUxCfoZTRdG9wJfkHUCAcfjDs8wdOU3Oi1weMPMp7l3v9Aq+ElGDXhpHkzMT4QXQ=

 

Cookie: TF_Framework_Cookies=T1Domain=T1Thick;

 

 

 

 

apparently my comma is due to a 2nd "Cookie" cookie.

 

 

The documentation states:

 

HTTP::cookie insert name value [path ] [domain ] [version <0 | 1 | 2>]

 

Adds a cookie to the HTTP Cookie header in requests or Set-Cookie response header. The default value for the version is 0. If the cookie already exists, a second cookie will be inserted (tested in 9.2.4).

 

 

 

I was assuming when it says if the cookie exists it will add a 2nd one it means a second cookie, not a 2nd cookie header

Multiple cookie headers are valid in an HTTP request and you can have multiple Set-Cookie headers in a response.

 

 

So is the corruption of the cookie values due to incorrect parsing of the two Cookie headers by something after LTM?

 

 

If so, and that can't be fixed, you could try manually setting the cookie in the request by modifying the Cookie header with the HTTP::header replace command. But it begs the question of what happens if a client or intermediate proxy has more than one Cookie header in a request.

 

 

Aaron

I guess I've never seen more than one Cookie header.

 

 

IIS is showing it as one cookie in the log with a comma as the separator.

 

 

When we ask for the cookie value in ASP.NET, it's giving us the cookie we want plus the appended cookie since it immediately follows the one we want. We get back from code what I included in my first post...everything after the name TFSessionId through the end minus the last semi-colon. I don't know why ASP.NET is giving us all that if you're saying that it's normal to have more than one Cookie header.

 

 

I think I'm missing something, but if when using the built in cookie objects in ASP.NET it stumbles over the 2nd cookie header, why would someone use the "HTTP::cookie insert" command?

 

 

I think I'm going to re-work the iRule to pull the cookie header and use string commands to rip it apart and rebuild it with my needed additions (if I can't find a matching cookie in the string) and then replace the cookie header with a new one. I have a feeling this is goin to chew up Big-IP processing, but I don't see how using the built-in cookie command is safe...

Not sure about the authority of the site, but this one says:

 

 

 

http://kristol.org/cookie/errata.htmlmulti-header

 

 

1. Can there be more than one Cookie header in a request?

 

 

Disposition:

 

 

We conclude that multiple Cookie headers may be present in a request. RFC 2965 has no specific words forbidding multiple Cookie headers, and the wording at least suggests the possibility of multiple headers.

 

 

2. Can multiple Cookie headers be combined?

 

 

If there can be more than one Cookie header in a request, can they be combined ("folded")?

 

 

Disposition: If so, then the syntax for Cookie needs to be changed.

 

 

Note: RFC 2616 (HTTP/1.1) says:

 

 

Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., (values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma.

 

 

In other words, multiple headers are allowed if and only if they can be combined.

 

 

 

 

So maybe it's not as clearly allowed in the RFC's. I know I've read that you can have multiple Set-Cookie(2) response headers. And this is something quite common to see.

 

 

You could check if the cookie exists with a value using 'HTTP::cookie exists $cookie_name'. You could modify the existing Cookie header using something like HTTP::header replace Cookie "[HTTP::header value Cookie]; new_cookie=new_value;".

 

 

It might also be interesting to check into the .NET code (or library?) you're using to see if there are any known issues/fixes for this. And you could open a case with F5 Support to see if they've seen other customers reporting a similar issue.

 

 

I'd be interested in hearing what you find out on any of these fronts.

 

 

Thanks,

 

Aaron

I am having the same problems. F5 cookie insert is doing things that IIS doesnt like. Its adding commas between new cookies, as described above. More specifically, it looks like F5 is adding a second Cookie header, which IIS is incorrectly trying to append them and shows the comma. In my case this is inadvertently trashing the ASPSESSIONID which breaks my app.

 

I would think the F5 should correct this and insert the new cookie to the end of the list of cookies in the existing Cookie header.