IIS 7 overwrites Set-Cookie when SessionState is enabled?

Apr 22, 2010 at 2:22 PM

I've got a call that gets proxied to a site that sets some cookies.

On the ASP.NET Development Server, the cookies come through

On IIS 7, the cookies come through only if I disable session state (Under Pages and Controls/Services/Set "Enable Session State" to false) or move the Session State into the URI.

Unfortunately, neither of these are viable solutions.

My thought is that the headers get copied by URL Rewriter and then get overwritten by ASP.NET.

Has anyone else encountered this?  Any ideas for a work around?

 

Thank you,

 

Scott

 

 

Coordinator
Apr 27, 2010 at 1:04 AM

You have to make sure your session cookies on the proxying server don't conflict with your session cookies on the internal server.  You can do this by changing the session cookie name that is used.

http://msdn.microsoft.com/en-us/library/h6bb9cz9.aspx

Please review this article for all the options available to you.

Apr 29, 2010 at 2:23 PM

Hi,

The cookies aren't the same as the ones used by ASP.NET session (They come from a Ruby app).

I opened  a case with MS as it looked like IIS was causing the problem.  They pointed to

the first line in ProxyHandler.SendResponseToClient

context.Response.ClearHeaders();  

When this is commented out, both the Set-Cookie headers and the ASP.NET session cookie arrive.

 

 

 

 

Coordinator
Apr 30, 2010 at 1:11 PM

I don't understand what that has to do with the original problem you posted.  You stated:

>> On IIS 7, the cookies come through only if I disable session state (Under Pages and Controls/Services/Set "Enable Session State" to false) or move the Session State into the URI.

The cookies from the proxied server get written directly to the header.  You stated that the cookies only come through if you disable the session state.  From your response above it sounds like just the opposite the cookies from the proxy server are coming through fine and just not showing the session state cookie.  So which problem should I be looking in to?

Also I don't think the response from Microsoft was too informed.  Because the session state cookies as far as I am aware is written to the header after the handler is executed when the request state is saved:

http://msdn.microsoft.com/en-us/library/system.web.httpapplication.releaserequeststate(v=VS.100).aspx

And this event happens after the proxy handler is executed.

http://msdn.microsoft.com/en-us/library/bb470252(v=VS.100).aspx

Even if all of the above wasn't correct, a reverse proxy is suppose to respond with exactly what the proxied request responds with.  It isn't suppose to add any extra headers or content.  Is there a reason you need this session header in your proxied content?  Because it is basically useless to the proxied server.

Nick

May 10, 2010 at 9:50 AM

Hi Nick,

I'm seeing something a little similar here. I have a JBoss application behind an IIS7 proxy and the proxy server is stripping the "set-cookie" HTTP headers from the server response.

Captures show:

1. Client sends login request. Proxy forwards to server

2. Server responds, including a set-cookie in the HTTP header

3. Proxy consumes this set-cookie and sends the response to the client "naked"

4. Client calls another page, sans-cookie. Server issues a new cookie, session is lost, authentication fails

Any suggestions? I've tried the suggested solution of disabling session-state for this app in IIS, but this has not changed anything.

 

Many thanks,

Daern

May 10, 2010 at 10:27 AM

More info:

As per ZedWonk's recommendation, I've commented out ClearHeaders(), and my app is now working fine.

I can't see any obvious implications of doing this, nor why you'd actually want to clear the server headers on the proxy (after all, it /is/ a proxy ;) )

 

Thoughts welcomed.

Daern

Coordinator
May 10, 2010 at 1:56 PM

The set-header if valid would be processed as part of the next line after the content and headers are cleared.

This is the response from the server that is being requested, it goes through each header and adds them.

for (int i = 0; i < response.Headers.Count; i++)

The line you are talking about and criticizing is for the response to the client from the proxy server, not the content from the server that was requested.

context.Response.ClearHeaders();

See the difference?  The context variable refers to the request being sent back to the browser, the response variable refers to the response from the server that was being proxied.  

 

So to answer your question 

>> I can't see any obvious implications of doing this, nor why you'd actually want to clear the server headers on the proxy (after all, it /is/ a proxy ;) )

With another question, why wouldn't you want the canvas cleared before writing the contents of the proxy to the response?  After all it is a proxy, and should only be showing the content that was actually sent back from the server, not stuff mixed in from ASP.NET setting up the response.  :)

 

By the way, I have tested the scenario you have been talking about, and I am not seeing the issues you are talking about.  Please provide a fiddler dump of the problem you are seeing.  You can put fiddler on your server and set it up to monitor both connections by uncommenting the <system.net> tag in the web.config.  You can attach the fiddler files to the issue I have created below.

 

Coordinator
May 10, 2010 at 1:57 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
May 10, 2010 at 2:12 PM

Many thanks for your reply Nick. Very interesting...

Would you settle for a Wireshark capture instead, as I'm already working with this on the server?

May 17, 2010 at 8:07 AM

For the benefit of others searching:

This issue appears to be an IIS7 problem and doesn't show up in IIS6. Making the change detailed above resolves it ok, albeit with a certain amount of noise in the HTTP headers. Perhaps an updated version that detects the IIS version and updates the headers accordingly would be a useful release...

Daern

Coordinator
May 17, 2010 at 6:51 PM

This issue is slated to be fixed in the next update.