1

Closed

Overwriting of Set-Cookie in Proxy

description

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.

file attachments

Closed Aug 13, 2010 at 7:47 PM by
Fixed in 3.5.3

comments

daern wrote May 10, 2010 at 2:41 PM

Ok, here's some logs (they're Wireshark, not Fiddler, but I hope this is ok. Apply an "http" filter and they're quite readable).

The files are:
client_failed.pcap - capture taken from the client browser PC using the 3.5 release
proxy_failed.pcap - capture taken from the proxy server using the 3.5 release
client_ok.pcap - capture taken from the client browser PC using the modified 3.5 release
proxy_ok.pcap - capture taken from the client browser PC using the modified 3.5 release

The key parts are the first HTTP response from the back-end server. (packet 8 in client_failed and packet 5 in proxy_failed) In this you can see the backoffice server returning:
Set-Cookie: JSESSIONID=uAq-xomRZxD2zSAMC91bHw**.node4; Path=/\r\n

...but the client doesn't see this and only sees the "standard" .NET crud.

Using the modified version, which has context.Response.ClearHeaders(); commented out from SendResponseToClient, the traces show that this set-cookie is no longer supressed and is passed to the client. Result: working application.

daern wrote May 10, 2010 at 2:57 PM

Ah, I see you don't like Wireshark. Here are the same dumps in text format.

Same data, just reformatted from the Wireshark trace :-)

nberardi wrote May 10, 2010 at 3:27 PM

I don't have Wireshark setup on my machine. Please use fiddler for now.

nberardi wrote May 10, 2010 at 4:10 PM

Seems to be a bug in IIS 7 handling, because it is working as it is suppose to on IIS 6. Issue probably needs to be opened with Microsoft on this.

daern wrote May 17, 2010 at 8:02 AM

Hi Nick,

Thanks for the update and apologies for the delay in responding. Can you think of any issues with continuing to run the code with context.Response.ClearHeaders(); commented out as we have done? We've done plenty of testing this week and it's working flawlessly, as far as we can see.

Many thanks for a great tool. Very useful.

Regards,

Daern

nberardi wrote May 19, 2010 at 11:47 AM

I can't think of any besides the obvious of mixing the proxy .NET headers with the headers from the server your are trying to proxy. This seems to be an IIS 7 issue. Which I can definitely see because if you ever look at the code for ASP.NET with reflector you will see a whole bunch of special cases built in to the framework for specifically IIS 7, that you won't see with IIS 6 or Cassini.