User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Waterfox/56.3

Steps to reproduce:

window.location.reload(); does not send session cookies upon execution.

Actual results:

Gecko will NOT send the session cookie.

Expected results:

Gecko should send the session cookie.

A work-around is to use window.location.href = window.location.href; however this is not intuitive. There is no third party software or non-session cookies involved.

The network panel will easily show the request headers do not include cookies.

Until recently for roughly the past eight months two-thirds of all people using Gecko browsers would not be able to maintain their sessions on any website powered by the JAB Creations web platform. I just determined this fix and will have to verify it over the next day or two.

It is possible that other methods to request a resource (e.g. new XMLHttpRequest()) may also fail to properly send the cookie in the request headers breaking the user experience and generating errors where there should be none.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Firefox 56 has been unsupported since November 14, 2017 and is an ancient insecure version.

Please run recent and secure software, and feel free to reopen this ticket if this still happens in a recent version of Firefox.
Please do not file any further issues about Firefox version 56 - we do not have a machine to travel back in time. :) Thanks!

I am using Waterfox as my primary browser and it's completely up to date thank you very much.

The bug applies to the latest versions of Firefox which I do not use unless I test or verify things like BUG REPORTS. I no longer use Firefox as it can no longer be (actually) customized.

You should probably verify the bug instead of blindly closing bug reports.

I am using Waterfox as my primary browser and it's completely up to date thank you very much.

Bumping the "Version" field in this ticket for no reason to "75 branch" (an unstable unreleased alpha version) does not make any sense.

If you use Waterfox as your browser then feel free to file bug reports in the issue tracker of Waterfox: https://github.com/MrAlex94/Waterfox/issues

Sorry, looks like a misunderstanding; in the future It would be tremendously helpful if you explicitly stated in an initial comment with which specific exact version of Firefox you ran into an issue.

Andre, I don't track the every three day releases. I have nearly over 80 profiles for various versions of Firefox and I test versions as far back as Gecko 0.8. In fact I have to forward port profiles if an instance of Firefox slips an update and invalidates a profile (Firefox 71 program loads on the profile for 70).

This bug goes a ways back, at least to Gecko 56. The "advanced" or original bug reporting form is well hidden in addition. If versions had any significant meaning and if more than 2 or 3% of the bugs I have filed over the past 15+ years were fixed I would STILL be posting high quality bug reports.

Thanks for the report!

John, can you please provide a simple test case (attached or online HTML page) I could use to reproduce the issue on my machine, thanks!

Honza

Hi Honza. A fair warning: this bug is really annoying to reproduce and beyond that even more annoying when you encounter it. I attempted to create a stand along test case though the Network panel for Firefox does not show HTTP requests unless the test case is running on a server (versus downloading and directly opening a standalone file).

The attached file is a screenshot of the visitors log for a Gecko oriented website I maintain. I've added some text and highlights to show how it has afflicted visitors to the website. The period is around when I discovered the issue and implemented a fix. Please keep in mind that you may run the test and never encounter the bug and I have no idea why hence the provided visitor log screenshot.

• This bug seems to occur for about two thirds of my visitors before I patched it.
• If the page loads correctly try a different profile.
• There is likely an unknown additional condition such as the cookie expiring at the server without the client realizing it.
• I have a profile for every major (and annoying minor) release of Firefox, some profiles are more apt to triggering the bug while others would never trigger the bug.
• The best I can do is a live test case with an HTTP query, there are some caveats however.
• I highly recommend opening a new blank tab, then opening the Network panel and THEN loading the URL.
• My system has an initialization process, in order for the site to use the location.reload() you'll need the HTTP query.
• My system apparently does not properly break cache as some users are not reading the catch page I've setup.
• If you encounter the bug and see the catch page a 10th request will result in being temporarily locked out.
• If you get locked out change your VPN's IP address to make another attempt.
• If you do not have multiple Firefox profiles I recommend duplicating them BEFORE you run the test.

https://www.jabcreations.com/docs/browsers/bugs/?gecko-bug-1617361=1

I can now confirm that the bug in the latest Beta 74 occurs when using the following:

window.location.href = window.location.href;

I've changed the Cache-Control header to "no-store, no-cache, must-revalidate" to ensure the fix was being pushed to overwrite the older bugged location.reload().

I don't suppose there is a reliable manner of reloading the page with which the HTTP cookie header is NOT randomly absent? I'm now seriously considering having to append the session to the request URL specifically for Gecko browsers which is beyond ridiculous.

The priority flag is not set for this bug.
:Honza, could you have a look please?

For more information, please visit auto_nag documentation.

Hi John, thanks for the update!

I attempted to create a stand along test case though the Network panel for Firefox does not show HTTP requests unless
the test case is running on a server (versus downloading and directly opening a standalone file).

I would be very interested in that page. I've installed local web server so, I could load it and reproduce the problem using that page. Can you share it?

Honza

Hi Jan, use the following PHP code to start the session and to list the session id:

<?php
//Save as bug_1617361.php in example
if (substr($_SERVER['DOCUMENT_ROOT'],0,1) == '/' && isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on')
{
ini_set('session.cookie_secure', 1);
ini_set('session.gc_maxlifetime', 3600);
session_set_cookie_params(3600);
}
ini_set('session.cookie_httponly', 1);
ini_set('session.cookie_samesite','Strict');
ini_set('session.use_only_cookies', 1);
session_name('session');
session_start();
echo '<p>Is the session id '.session_id().' the same as the last page load? If not your browser likely did <em>not</em> set the HTTP Cookie header.</p>';
?>

Sometimes one of my Firefox profiles will become "stuck" and therefore easy to reproduce the issue. If you have trouble reproducing the issue I will attach the profile for you to load though are there limitations to the file size that can be uploaded? These are roughly ~80MB (I always browse with cache disabled).

The priority flag is not set for this bug.
:Honza, could you have a look please?

For more information, please visit auto_nag documentation.

Ah, I don't have HTTPS setup locally. Any chance to put this online?

Honza

Could this be recreated used glitch? https://fireox-devtools-testcase-dynamic-script.glitch.me/ logs the session id as well and runs over HTTPS. I can't reproduce the issue though.

Would attaching a HAR file help to diagnose the requests/responses?

Two people found the bug in relation to this bug report. The past two days I'd say 90%+ encountered the bug (normal traffic, not bug hunting) on fixedfirefox.com also had their visits come to a complete halt.

Jan, I occasionally encounter this bug locally and unless I'm testing something financially related I don't need https:// for localhost.

Some possibilities that crossed my mind with this bug:

• Possibility that this bug may be caused by the corruption of part of a profile?

• Issue with PHP somehow, in example there is another HTTP bug where after giving a location header if die(); wasn't used then Firefox wouldn't load the URL from the header.

• Perhaps the bug is triggered after a session is supposed to expire?

I've been testing two domains on my system and having no success reproducing it at the moment.

If someone reproduces the bug I recommend making a copy of their Firefox profile and posting it for others to share (after clearing out bookmarks, passwords, etc). The moment I can reproduce this on a live domain I'll do so myself.

I am setting the priority to P3 (to stop the bot posting comments) but, I am leaving the status as UNCONFIRMED until somebody can provide reproducible test case.

Honza

Honza, I am maybe missing how DevTools is related to this. Should this maybe be in Necko?

Good call, moving to the Networking component for further triage.

Honza

Hi Reporter,

Could you try to capture the http log?
It'd be very helpful.

Thanks.

@Kershaw I'm having trouble reproducing the issue directly. Is it possible that even with log persistence in the Network tools that not all requests are displayed? After clearing requests in my database (table that handles IP addresses temporarily) I still up to 12 HTTP requests on the server from my IP though I do NOT see those requests - which to me screams a bug, a (new?) DIFFERENT bug that is not what I'm reporting. I still get locked out of my system and have to manually flush my IP out. I uploaded a couple logs as the upload limit here is 10 MB.

https://www.jabcreations.com/files/moz/

You can reverse look up domains on the server IP. The session life span is 30 minutes so perhaps testing after it "expires" is one approach. I've also cleared absolutely everything from Firefox and it won't trigger though almost all of the visitors at fixedfirefox.com are first-time visitors. I can't overemphasize enough how difficult to reproduce this bug is and I still have great difficulty reproducing it after eight months of having to deal with it. I'm open to suggestions on various behaviors of requests to try out.

While doing unrelated maintenance for Firefox browsers I encountered the bug on localhost, the file main.11460.log contains the rapid succession of requests that this bug originally describes. Hopefully this helps!

(In reply to John A. Bilicki III from comment #24)

Created attachment 9133520 [details]
main.11460.log

While doing unrelated maintenance for Firefox browsers I encountered the bug on localhost, the file main.11460.log contains the rapid succession of requests that this bug originally describes. Hopefully this helps!

Can you please state with EXACT request is the one that should have the cookie and doesn't?

Honza, the request was for http://localhost/Version%203.2.0/www.jabcreations.com/.

I noticed that for my own encounters after I cleaned the database of the "reject" requests and cleared the browser cookies that the local site loaded correctly. This is in addition to people encountering the bug on live websites that (as far as I know) for the most part have never before visited those domains.

(In reply to John A. Bilicki III from comment #26)

Honza, the request was for http://localhost/Version%203.2.0/www.jabcreations.com/.

I noticed that for my own encounters after I cleaned the database of the "reject" requests and cleared the browser cookies that the local site loaded correctly. This is in addition to people encountering the bug on live websites that (as far as I know) for the most part have never before visited those domains.

There's 12 of them in the log, 11 with 202 response, 1 with a 302 -> 503. Is the cookie that we should be sending back session=....; path=/; HttpOnly? You report is lacking some basic details what to actually look for.

You may also add cookie:5 to the list of modules (MOZ_LOG) next time you are capturing a log. It will add some helpful info.

Thanks.

Honza, when the bug occurs what I discovered previously is that the HTTP 'Cookie' header was NOT being sent in the headers request. That in turn makes my system think that this is a new session. This creates a loop until it breaks the server tolerance level eventually resulting in the HTTP 503 you see at the end.

I'm looking at it from the Network panel's perspective. I also go far out of my way to ensure I'm up to date on various aspects like validators, website tests, standards, etc.

In the Network panel after clearing cookies and the database on localhost, then loading the site, clearing the server's validation I cleared the Network panel and then made another request with the existing session cookie.; the Network panel reports "Cookie: session=ajo3aj5ed3fb7lecs93orta44p" for the header request. I'm aware that there are various validation aspects for cookies though haven't worked with them for at least half a year though they do look correct offhand. The ~6MB file is a bit more than I can wade through at the moment though if there is a more explicit though still relatively reasonable aspect of the HTTP headers that I can look through I can verify what a normal cookie on my server looks like.

There are a limited few differences in my software between the local and live ("production") environments. Locally I run a WAMP, live I'm running a LAMP. Nothing cookie related changes though if there is anything Apache related to cookies I'd be happy to post that. The PHP code for starting the session is used both on the local and live servers. The cookies on the local server never expire (from what I can tell) which seems to make it easier to test (earlier today I was testing the live servers with little-to-no luck). I'll be around for a few more hours to hopefully help you zero in on the issue.

(In reply to John A. Bilicki III from comment #28)

Honza, when the bug occurs what I discovered previously is that the HTTP 'Cookie' header was NOT being sent in the headers request. That in turn makes my system think that this is a new session. This creates a loop until it breaks the server tolerance level eventually resulting in the HTTP 503 you see at the end.

(Still referring the log from comment 24)

I can see Cookie: member=5lkc9j006n0eecm9usoood0js6 being set on ALL requests to http://localhost/Version%203.2.0/www.jabcreations.com/, including the one that get a 302 response, going to http://localhost/Version%203.2.0/www.jabcreations.com/?h=1, responding with 503.

What EXACT cookie do you expect us to be sending with the request?

I can see Set-Cookie: session=dlamrknuvh8nrgeo6ogpive8ps; path=/; HttpOnly being sent by the server, which I then don't see being sent back in the request. Is this the bug?

I can see Set-Cookie: session=dlamrknuvh8nrgeo6ogpive8ps; path=/; HttpOnly being sent by the server, which I then don't see being sent back in the request. Is this the bug?

YES! When Firefox does NOT send the HTTP 'Cookie' header then THAT is what this entire bug report is about.

It would be great if you captured a log with cookie:5 module included in MOZ_LOG. It may give us a quick answer why we don't store the session cookie. Thanks.

Honza, that would have been nice to know the first time. Luckily I had copies of the profiles in an older backup of the AppData directory. Go to the URL I linked and download the file main.10408.log. The URL requested is http://localhost/Version 3.2.0/www.jabcreations.com/. If the answer is there I would love to understand how to read this log for future purposes.

(In reply to John A. Bilicki III from comment #32)

Go to the URL I linked and download the file main.10408.log.

thanks, which URL?

Where do I download "the file main.10408.log" ?

2020-03-16 15:51:56.994000 UTC - [Parent 10408: Main Thread]: W/cookie ===== COOKIE NOT ACCEPTED =====
2020-03-16 15:51:56.994000 UTC - [Parent 10408: Main Thread]: W/cookie request URL: http://localhost/Version%203.2.0/www.jabcreations.com/
2020-03-16 15:51:56.994000 UTC - [Parent 10408: Main Thread]: W/cookie cookie string: session=s1q1c3mk7718ia0b9sebu8ktop; path=/; HttpOnly
2020-03-16 15:51:56.994000 UTC - [Parent 10408: Main Thread]: W/cookie current time: Mon Mar 16 15:51:56 2020 GMT
2020-03-16 15:51:56.994000 UTC - [Parent 10408: Main Thread]: W/cookie rejected because cookie can't save because older cookie is secure cookie but newer cookie is non-secure cookie

Yeah no.

I changed the session cookie name so the 'session' cookie will be ignored and 'session2' will be used instead about two days ago. With these changes the no HTTP Cookie bug is still effecting ~90% of all Firefox users and preventing them access to any of the sites powered by my platform.

I need logs from a life case then.

Then, if you made more clear that the URL in comment 8 is actually a test case, I could test with it. Can you change the IP blacklist expiration to only some 60 or 30 seconds for that test case, so that I can test with it? I was able to reproduce once by accidental clicking, but the test case was then gone to check again...

Honza...

• I've temporarily increased the spam-tolerance per IP address from 10 to 100.
• Do you have a VPN to try from a new IP address?
• I am happy to remove instances in the database of an IP address if/when you hit the security wall though I have no even semi-easy way to compensate for that system limitation or to create one for about two months.
• I can provide a Firefox profile that at least encounters the bug on localhost (much harder for live servers though).
• Today I'm migrating all domains to a new account as (apparently) Cent OS can not directly upgrade from 6 to 7 so there may be down time so if the server becomes unavailable you know why. I also have to update the DNS servers to new addresses (the current "old" server IP is 162.254.253.154).
• I have created a new bug for the secure cookie issue you mentioned NOT pushing an error to the normal developer console here: https://bugzilla.mozilla.org/show_bug.cgi?id=1623284.
• Please keep in mind that (in my experience) some profiles REALLY love to trigger this bug and some NEVER trigger it. If I clear out cookies on the ones that do then it seems to stop altogether (before I patched it and supposedly all cookies were secure).
• I am NOT aware of how my system was sending nonsecure cookies AFTER secure ones were sent though I have posted all the related PHP session code earlier/above.

I'd really like to confirm or disprove this bug eventually, but I can't move forward w/o a public test case that can be used repeatedly or a log from a client experiencing the bug on the live site. The cause of /a/ bug in main.10408.log has been identified and I'd guess is a different cause than what happens to live clients of your platform.

Honza, the best that I can directly provide is to strip down a Firefox profile where the issue occurs on localhost and attach that profile for testing purposes. I'm also willing to grant assistant webmaster permissions so you can personally go see how bad the visitors log is effecting people at the Fixed Firefox. I also opened a thread and have had a little assistance trying to help address the bug: https://www.reddit.com/r/firefox/comments/flf7at/help_prevent_a_browser_monopoly_easy_help_to_keep/

Question: in my Firefox profile I notice that (while everything appears to be operating normally) that the server does NOT respond with the set-cookie header though the client (my browser) does send the Cookie header. I would imagine that the server SHOULD send the cookie header per request. Is there a chance that this itself could somehow throw off Gecko at some point?

I've also hit this issue (from one of the two machines I tried it on). I took a screenshot of the request/response headers. How do I attach an image?

@abrick Thank you for posting. In the Network panel can you please check the Persist Log? I took the image you posted and outlined it in green.

If you're on Reddit or Twitter please directly message me with the last D section of your IP (e.g. AAA.BBB.CCC.DDD) so I can remove the security mechanism blocking your IP and you can retest.

Then when you retest please make sure to click on a request before the HTTP 503 error. That is where Firefox is NOT sending the Cookie header to the server and that is what the Mozilla developers are trying to reproduce. Thank you so much for taking the time to help!

I realized that I could generate logs. As of this morning I am now capturing both incoming client and outgoing server headers.

I attempted to find a validator for setting cookies and could not find one. If it helps I will post more logs, this is the only one I have available at this time though I should have plenty in a few hours.

Not a lot of traffic today though I came across a user who loaded a page, got past the security and a few moments later decides to go to the front page. When they do their session cookie suddenly goes bad.

I've also been searching the web and it's clear that at some point the Firefox profile's cookie file is likely getting corrupted somehow. My software doesn't set 10+ cookies, typically 3 or less if even. There are a multitude of issues with cookies.

I have been randomly logged out of sessions though not as often as this problem has plagued others. Is the cookie expiration being updated per request? Is the time zone off? I'm not entirely sure. There may be additional volatility with the advanced flags though I'm waiting for more traffic before I can come to any modest conclusions in that regard.

http://forums.mozillazine.org/viewtopic.php?f=38&t=2273021

This https://stackoverflow.com/a/53109456/606371 person references this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=263057
...which is still open! No 404s in this log for that IP though.

Again though this person is using ASP/C#:
https://stackoverflow.com/questions/56009221/does-anyone-else-have-issues-losing-session-variables-in-firefox-but-not-in-chro

Another having issues with the advanced flags:
https://stackoverflow.com/questions/52763345/browsers-ignore-set-cookie-response-header-if-we-try-to-set-a-cookie-which-was-s/55478559

There are more lost among the chaos of people making simple mistakes.

The priority flag is not set for this bug.
:dragana, could you have a look please?

For more information, please visit auto_nag documentation.

It's been days and there has been a lot more traffic on all the websites that I maintain on my platform. I have come to a some deductions based on my latest fix.

I am manually stripping the set-cookie header and manually creating it (either PHP or the HTTP server is appending the secure flag).

set-cookie: session3=c5cde9ef62110e2a5bbe6c8d3e7c728ee; path=/; domain=www.fixedfirefox.com; secure

On websites that are NOT technically oriented the failure rate for Firefox is exceptionally low, I would say less than 1% are afflicted (mostly from my browsers somehow leaking requests when no tabs are open other than localhost, because there aren't enough bugs intersecting cookies already). However on the much more technically inclined websites the failure rate is much higher, sometimes pressing 95% failure rate.

From everything thus far these are my deductions:

• Firefox does randomly drop sessions by NOT setting the cookie header from time to time for all users thus breaking sessions.
• Technical users are likely to have Firefox profiles with the cookies.sqlite file likely having issues, very likely corruption.
• PHP is inconsistent with session cookies at least in regards to advanced flags (besides the secure flag).
• I have come across errors such as NS_ERROR_FILE_CORRUPTED in reference to broken localStorage further stressing that there are issues with Firefox profiles.
• I only see four bug reports that reference the cookies.sqlite file.

I was having similar issues for the last few years(?). But with the hint of cookies:5 in MOZ_LOG I finally found the problem: too many cookies on the same domain.

But without that hint, this problem was extremely hard to pin down. It seemed like some form of profile degradation. Refreshing the profile seemed to solve it for a few months, then it started happening again. Removing cookies.sqlite seems to solve it for a few hours/days but it got gradually worse and worse until I needed a new profile refresh.

Also, I'm very unclear on the lifetime of "Session" cookies. Because even when I uncheck "Restore previous session" (normally I have it checked) and I close and restart the browser, all the Session cookies seem to have survived the restart. We have many applications running on the same root domain (with unique, sometimes autogenerated subdomains). One of them is in a pinned tab (which maybe explains the session cookies surviving the restart?). Another one was steadily generating more and more session cookies (162 by today) and at some point a third application (which does not use secure cookies) got this error:

2020-07-20 11:04:33.176785 UTC - [Parent 8427: Main Thread]: D/cookie ===== COOKIE EVICTED =====
2020-07-20 11:04:33.176802 UTC - [Parent 8427: Main Thread]: D/cookie Too many cookies for this domain and the new cookie is not a secure cookie
2020-07-20 11:04:33.176810 UTC - [Parent 8427: Main Thread]: D/cookie current time: Mon Jul 20 11:04:33 2020 GMT
2020-07-20 11:04:33.176813 UTC - [Parent 8427: Main Thread]: D/cookie ----------------
2020-07-20 11:04:33.176819 UTC - [Parent 8427: Main Thread]: D/cookie name: PHPSESSID
2020-07-20 11:04:33.176834 UTC - [Parent 8427: Main Thread]: D/cookie value: [redacted]

So maybe some kind of warning like a yellow notification bar on top saying "This site is generating too many cookies" or something might be in order?