Problem: Ape 3.1.0.105 with multiple Set-Cookie Headers

[swobi Profile]

Hi!

We are using Ape 3.1.0.105 with mode_rewrite, mod_proxy and mod_replace.

In a reverse proxy scenario we have to proxy calls to /prefix/... to /...
and then change the links in the response back to /prefix/...

This works with mod_proxy and mod_replace.

The problem we have is with the following Cookie Path correction:

HeaderReplacePattern myproxy Set-Cookie Path=/(?!prefix) Path=/prefix/

When there are multiple Set-Cookie headers the following happens:

without HeaderReplacePattern
Set-Cookie: JSESSIONID=....; Path=/
Set-Cookie: SPECIALID=....; Path=/
Set-Cookie: SPECIALID2=....; Path=/

with HeaderReplacePattern
Set-Cookie: JSESSIONID=...; Path=/prefix/,SPECIALID=....; Path=/prefix/,SPECIALID2=....; Path=/prefix/

So HeaderReplacePattern seems to combine the multiple Set-Cookie headers and some browsers are not able to handle this.

I found a bugfix entry in ISAPI_Rewrite 3.1.0.60: multiple Set-Cookie: headers processing in proxy extension

Could this be a similar problem?

please help
swobi

[Anton]

Hello,

"So HeaderReplacePattern seems to combine the multiple Set-Cookie headers and some browsers are not able to handle this."
- combining several identical headers into one is implied by RFC standard and it's .NET which is doing that.
Please specify the browser(s) which are unable to handle that.

"I found a bugfix entry in ISAPI_Rewrite 3.1.0.60: multiple Set-Cookie: headers processing in proxy extension"
- ISAPI_Rewrite and Ape are not related products and the same directives are realized in a completely different way, so the bugfix you've found has no relation to Ape.

[swobi Profile]

Hi Anton!

Thanks a lot for your answers.
I did some research (aka Googling and found some interesting articles:

A page were you can test various cookie combinations
http://staff.washington.edu/fmf/2009/06/19/setting-cookies/

FIX: Multiple cookies may be merged under one Set-Cookie header in the HTTP response when a .NET Framework 2.0 application calls the "HttpListenerResponse.SetCookie" method
http://support.microsoft.com/kb/933905

combining several identical headers into one is implied by RFC standard and it's .NET which is doing that.

I also tried it with mod_headers:
Header edit Set-Cookie "Path=/(?!prefix)" "Path=/prefix/"

But since .NET is merging the Set-Cookie headers it is clear why I get the same result.
Someone mentioned that there are different contradicting RFCs regarding Cookies.

Please specify the browser(s) which are unable to handle that.

Mobile Safari (iPad), IE10 and Firefox 28 are the ones I tested on and all of them did only set the first cookie when the combined Set-Cookie header is received. The Cookies are set on a redirection page (HTTP 302) and because the session cookie is not set the webapplication starts a "happy" redirection loop.


BTW: We need the CookiePath correction only because our proxy rules (http.conf) are doing the proxying fine but not the CookiePath correction.

This is what we are using:

Code: Select all

<Location /prefix/>
    ProxyPass                       https://www.protectedserver.com/
    ProxyPassReverse                https://www.protectedserver.com/
    ProxyPassReverseCookieDomain    www.protectedserver.com  www.publicserver.com
    ProxyPassReverseCookiePath      /    /prefix/
</Location>

Should this work?

cheers
swobi

[Anton]

Hello, Swobi

Your proxy rules look fine, so please provide us the Ape logs (error.log and rewrite.log) for investigation to [email protected] with reference to this post.
As for the cookie issue, please show us the exact cookies you get.

[swobi Profile]

Hi again!

Your proxy rules look fine, so please provide us the Ape logs (error.log and rewrite.log) for investigation to [email protected] with reference to this post.

I'll turn on debugging tonight and test the proxy rule again.

As for the cookie issue, please show us the exact cookies you get.

After some fiddling around with Fiddler2 I found out what happens in the different browsers (and why only our iPad customers are complaining).

The original Set-Cookie headers look like that (the actual ID is always the same and is replaced with ...):

Code: Select all

Set-Cookie: JSESSIONID=...; Path=/someappurl; Secure
Set-Cookie: SSOSESSIONID=...; Path=/
Set-Cookie: SSOSESSIONID=...; Path=/
Set-Cookie: SSOSESSIONID=...; Path=/

When they are not rewritten everything works fine.

The rewritten Set-Cookie header looks like that:

Code: Select all

Set-Cookie: JSESSIONID=...; Path=/prefix/someappurl; Secure,SSOSESSIONID=...; Path=/prefix/,SSOSESSIONID=...; Path=/prefix/,SSOSESSIONID=...; Path=/prefix/

and on the next page

Code: Select all

Set-Cookie: SSOSESSIONID=...; Path=/prefix/,SSOSESSIONID=...; Path=/prefix/,SSOSESSIONID=...; Path=/prefix/

Now there actually are two problems:

1) .NET combines the Set-Cookie header
In IE10 and Firefox28 on the first page (http redirect 302) the first cookie (JSESSIONID) is set and on the next page the JESSIONID Cookie is sent in the Request and the new first cookie (SSOSESSIONID) is set.
Therefore the SSO Session Handling (kind of) works.

2) third-party webapp sets the same SSO cookie multiple times in one response
This is no problem in IE10 and Firefox28, BUT Mobile Safari on the iPad can not deal with this.
Therefore the SSO cookie is never set and the browser loops on the redirect.

As soon as I deleted the additional SSOSESSIONID cookies from the response header Mobile Safari (iPad) could also set it correctly!

Thanks for your help!
swobi