Flash Data causes IE to balk

[eluser]bretticus[/eluser]
To my great surprise, I have found that after setting flash data cookies and then redirecting, IE will turn up a "IE Cannot display the webpage" error (friendly messages are off.) Looking at the headers in IE, IE does not even attempt to load the page indicated by "Location:" in the header.

Anyone else have this issue? Can you give me some IE insight perhaps? This is how the headers look in IE:

(ci_session keys shortened for brevity.)

HTTP/1.1 302 Found
Date: Wed, 02 Sep 2009 17:11:28 GMT
Server: Apache
X-Powered-By: PHP/5.2.6
Set-Cookie: ci_session=VzUMOFQ7VmQNAIgCTRaKQ==; expires=Wed, 02-Sep-2009 19:11:29 GMT; path=/
Set-Cookie: ci_session=UTMOOgBvBrV2oNfg==; expires=Wed, 02-Sep-2009 19:11:31 GMT; path=/
Set-Cookie: ci_session=UTNdaQFuUWNX4Acw==; expires=Wed, 02-Sep-2009 19:11:31 GMT; path=/
Set-Cookie: ci_session=B2UPO1E+BjRcg==; expires=Wed, 02-Sep-2009 19:11:31 GMT; path=/
Set-Cookie: ci_session=C2lYbFA%2NFJwOfQ==; expires=Wed, 02-Sep-2009 19:11:31 GMT; path=/
Location: http://www.dixiecenter.com/shopping/shop...ut_success
X-ProcessTime: D=3154187
X-NodeName: custweb02
Content-Length: 0
Keep-Alive: timeout=100, max=84
Connection: Keep-Alive
Content-Type: text/html

This works fine in firefox or any other browser (of course.) Here's my headers in FF (number of cookies isn't consistent. Sample data only.)

HTTP/1.x 302 Found
Date: Wed, 02 Sep 2009 17:24:24 GMT
Server: Apache/2.0.59 (Unix) PHP/5.2.6 DAV/2
X-Powered-By: PHP/5.2.6
Set-Cookie: ci_session=nmqohY4HUxzM0oGC8qp98bgUBrW6; expires=Wed, 02-Sep-2009 19:24:25 GMT; path=/
Set-Cookie: ci_session=QfhDBLwIURtY5aZ4N31Fkv; expires=Wed, 02-Sep-2009 19:24:25 GMT; path=/
Set-Cookie: ci_session=Zt0HJv4/ltnwM; expires=Wed, 02-Sep-2009 19:24:25 GMT; path=/
Set-Cookie: ci_session=yFRjAL5sAT3/hjv; expires=Wed, 02-Sep-2009 19:24:26 GMT; path=/
Location: http://dixiecenter.home/shopping/shop/checkout_success
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

There seems to be a cookie set for every item of flash data. Does IE balk if there are "too many" cookies?

Here's my code:

Code:

//store order info for success page
$this->session->set_flashdata('order_id', $order_id); //int

//store cart_info for success page
$this->session->set_flashdata('cart_info', $cart_info); //array

//store billing information for success page
$this->session->set_flashdata('tax', $tax);
$this->session->set_flashdata('bill_first', $bill_first);
$this->session->set_flashdata('bill_last', $bill_last);
$this->session->set_flashdata('bill_address', $bill_address);
$this->session->set_flashdata('bill_city', $bill_city);
$this->session->set_flashdata('bill_state', $bill_state);
$this->session->set_flashdata('bill_zip', $bill_zip);
$this->session->set_flashdata('sub_total', $sub_total);
$this->session->set_flashdata('total', $total);
$this->session->set_flashdata('cc_card', truncate_card(card_number_clean($cardnum)));
if ( !empty($vendor_data) && is_array($vendor_data) && count($vendor_data) >= 2 )
    $this->session->set_flashdata('company', $vendor_data[1]['Company']);
else
    $this->session->set_flashdata('company', '');

//redirect('shop/checkout_success/' . $order_id);
log_message('debug', 'flash data set, redirecting');
redirect('shop/checkout_success');

[eluser]bretticus[/eluser]
Perhaps a moderator can move this to Bug Reports???

[eluser]kurucu[/eluser]
Have you tried setting only one flashdata, as per your own suggestion?

[eluser]wabu[/eluser]
Maybe it's not too many, but too much?

There's a bunch of articles that discuss how the per-host limit was raised from 20 to 50 in 2007, such as:

http://blogs.msdn.com/ieinternals/archiv...s-FAQ.aspx

But check this out (even though it's from 2006):

http://www.thismuchiknow.co.uk/?p=13

"Instead, it seems to have a maximum size of 4096 bytes for all cookies from a domain."

Looking over the values you're setting, could 'cart_info' be the culprit (because the other items look smaller)? How about removing items one by one until it works?

Here's a somewhat more recent summary for all browsers (though it doesn't discuss the site-wide limitation):

http://ajaxian.com/archives/browser-cook...n-research

[eluser]kurucu[/eluser]
You could also pop your session into the DB, which might fix this problem without any other coding.

The user guide has a good section on this in the sessions section. Once done, you need to code no differently, but CI stores the cookie data in the DB instead.

[eluser]bretticus[/eluser]
Thanks for the responses. It struck me as odd that my flash data was in cookies where the sessions are setup in the database already (actually, that seems appropriate for flash data come to think of it.) Also, I was surprised that there was a cookie for each item of flash data.

cart_info in all of these cases was relatively small (perhaps 100-200 bytes.) I do have encryption turned on and a large random key (63 chars.) The base64 strings that result do seem to be quite long. Although I did check the string length and came up with approximately 600 chars or 600 bytes. Large, but not massively large (and much less than 4096.)

In the interest of time, however, I had to revamp my checkout methods and use a random token to pass to the URL and perform a database lookup to show success details.

I will have to do some additional testing. I was hoping that someone could confirm or refute this issue. Your comments are greatly appreciated. I will follow your suggestions when I have a moment to test further.

[eluser]bretticus[/eluser]
[quote author="kurucu" date="1252003361"]You could also pop your session into the DB, which might fix this problem without any other coding.[/quote]

Great suggestion and I did just end up storing the cart_info array in the database session (I didn't want to render it again which is why I stored it in flash data in the first place.) I have a call to a method in my controller constructor that cleans it up if the method name is different from the success page method. Works the same as flash data was working for me.

Thanks

[eluser]jhabbley[/eluser]
Interestingly, I just ran across a very similar and related problem with Chrome.

We're using flashdata to store some parameters chosen in a simple "filter search results" form so we can page through the data without having to put all of the criteria back into the "next page" or "page 2" links. Works great.

However, depending on the number of flash variables we were setting, we'd eventually get this error in chrome: "Error 325 (net::ERR_RESPONSE_HEADERS_TOO_BIG): Unknown error."

Upon viewing the Response Headers (in Firefox), I saw this:

Code:

Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: PHP/5.2.5
Set-Cookie: ci_session=a:4:{s:10:"session_id"%3 (... snip ...); expires=Tue, 15-Sep-2009 23:12:18 GMT; path=/
ci_session=a:4:{s:10:"session_id"%3 (... snip ...); expires=Tue, 15-Sep-2009 23:12:18 GMT; path=/
ci_session=a:4:{s:10:"session_id"%3 (... snip ...); expires=Tue, 15-Sep-2009 23:12:18 GMT; path=/
ci_session=a:4:{s:10:"session_id"%3 (... snip ...); expires=Tue, 15-Sep-2009 23:12:18 GMT; path=/
ci_session=a:4:{s:10:"session_id"%3 (... snip ...); expires=Tue, 15-Sep-2009 23:12:18 GMT; path=/
ci_session=a:4:{s:10:"session_id"%3 (... snip ...); expires=Tue, 15-Sep-2009 23:12:18 GMT; path=/
(... approximately 25 lines removed ...)
Date: Tue, 15 Sep 2009 21:12:20 GMT
Connection: close

Because we're using the DB for sessions, each of the lines beginning with "ci_session=" was identical... and repeated over and over again.

After looking into the Session library, I found the culprit: Each time set_flashdata is called, Sessioness_write is eventually called.

If you're NOT using the DB for session data, then you MUST rewrite the cookie each time a new flashdata variable is set (as the data is stored in the cookie). Makes sense.

However, if you ARE using DB for session data, it still writes out the cookie again... even though only no cookie data has changed (session_id, ip_address, user_agent, and last_activity all remain the same, and user_data is stored in the DB).

So I modified the Session library slightly to fix this:

In /system/libraries/Session.php, I made these changes:
(in the member variable declarations)

Code:

class CI_Session {

    var $_cookie_data_written         = FALSE; //add this variable

(at the end of sess_write function)

Code:

//
        // Write the cookie.  Notice that we manually pass the cookie data array to the
        // _set_cookie() function. Normally that function will store $this->userdata, but
        // in this case that array contains custom data, which we do not want in the cookie.
        if($this->_cookie_data_written === FALSE) {
            $this->_set_cookie($cookie_userdata);
            $this->_cookie_data_written = TRUE;
        }
    }

Basically, once the cookie has been written to the browser... don't bother writing it again, as it contains no new information.

I hope this helps somebody that runs into this same problem.

[eluser]bretticus[/eluser]
[quote author="jhabbley" date="1253069738"]Because we’re using the DB for sessions, each of the lines beginning with “ci_session=” was identical… and repeated over and over again.[/quote]

Man, I wish I would have saved my code to try that out. I, interestingly enough, got different values for "ci_session=". Do you have the encryption key set by chance?

Code:

$config['encryption_key'] = 'something';

Thanks for doing the research here.

Brett

[eluser]jhabbley[/eluser]
[quote author="bretticus" date="1253071410"]
Man, I wish I would have saved my code to try that out. I, interestingly enough, got different values for "ci_session=". Do you have the encryption key set by chance?
[/quote]

For the purposes of this example, I disabled encryption. (I wanted to verify that the contents of each of the cookies was the same)

Before I disabled it, the encrypted values for ci_session were all different. But that's more of an effect of the encryption method, I believe. (mycrypt uses a randomized encryption method)

I've since re-enabled encryption, and everything is still working as expected.