Open Bug 1672233 Opened 2 years ago Updated 1 year ago

Our members are unable to connect to our website since the last version 82.0 It's the same problem as on one of the previous versions!

Categories

(Core :: DOM: Core & HTML, defect)

Firefox 82
defect

Tracking

()

People

(Reporter: waxmax, Unassigned, NeedInfo)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

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

Steps to reproduce:

Our members are unable to connect to our website since the last version 82.0 It's the same problem as on one of the previous versions! Members remain on the home page of our site. Refreshing the page will load the rest.

Actual results:

Members blocked on the home page after login

Expected results:

The page of the site after connection should load normally.

Hi Walter!
Please could you add some test cases or more exact steps or the Website URL to test this issue? Also, you can try to reproduce this problem on latest Nightly, download it from here: https://nightly.mozilla.org/

Flags: needinfo?(waxmax)

https://demo.wowonder.com/
Open an account here and try to login on this script. You'll see. Once connected, the page must be refreshed to go further. On Chrome and Opera, there is no problem but on Firefox, it blocks! This bug has already been resolved after version 81 and then now in version 82.

Flags: needinfo?(waxmax)

Hi,
Thank you for your reply. I was able to reproduce it on latest Nightly version 84.0a1 (2020-10-30)(64-bit) on Windows 10. After refreshing the page the webpage was loaded completely. I will attach a file with web console information.
I will set a component, please If you consider that there's another component that's more proper for this case you may change it.

Component: Untriaged → Sync

The suggested severity revolves around S3 since the action can be finished after the refresh is done.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Not sync related

Component: Sync → Untriaged

I'll set a component, please If you consider that there's another component that's more proper for this case you may change it.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

(In reply to Walter from comment #0)

Our members are unable to connect to our website since the last version 82.0 It's the same problem as on one of the previous versions! Members remain on the home page of our site. Refreshing the page will load the rest.

Seems like a regression? Marcela, could you try to find the regression window? Thanks!

Flags: needinfo?(marcela.calderon)

Bug 1668577 claims to be in the 83 branch, but comment 0 says this regression happens in 82...

Flags: needinfo?(bugs)
Regressed by: 1668577

bug 1668577 should change behavior in Fission only.
But let me test.

I can reproduce the behavior in a built just before bug 1668577 .

Flags: needinfo?(bugs)
No longer regressed by: 1668577

Hello ! For information, this bug is still not resolved in the latest version 82.0.3 . It's very long and our customers are starting to get impatient that they can't use Firefox on this script that we sell. You corrected it following version 81, why this problem which is not present on Chrome or Opera? cordially

In the console, there is a warning when you try to login:

Cookie “user_id” has been rejected because it is already expired.

How is that cookie getting set?

(I can try to poke, but the above may help)

Flags: needinfo?(emilio)
Regressed by: 1649807
No longer regressions: 1649807
Has Regression Range: --- → yes

So I think this is invalid, you're sending the following in the http response:

Cache-Control: max-age=846000
Pragma: no-cache

Those are conflicting instructions. Firefox is choosing to honor the modern Cache-Control header, and Chromium is honoring the Pragma one.

So I think this is a server misconfiguration. Do you agree?

Flags: needinfo?(emilio) → needinfo?(waxmax)

See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Pragma:

Note: Pragma is not specified for HTTP responses and is therefore not a reliable replacement for the general HTTP/1.1 Cache-Control header, although it does behave the same as Cache-Control: no-cache, if the Cache-Control header field is omitted in a request. Use Pragma only for backwards compatibility with HTTP/1.0 clients.

Something like this of course "fixes" it:

diff --git a/netwerk/protocol/http/nsHttpResponseHead.h b/netwerk/protocol/http/nsHttpResponseHead.h
index 4126acd13398..75c3d1500a36 100644
--- a/netwerk/protocol/http/nsHttpResponseHead.h
+++ b/netwerk/protocol/http/nsHttpResponseHead.h
@@ -194,9 +194,8 @@ class nsHttpResponseHead {
   }
 
   bool NoCache_locked() const {
-    // We ignore Pragma: no-cache if Cache-Control is set.
     MOZ_ASSERT_IF(mCacheControlNoCache, mHasCacheControl);
-    return mHasCacheControl ? mCacheControlNoCache : mPragmaNoCache;
+    return mCacheControlNoCache || mPragmaNoCache;
   }
 
  private:

But I don't think we should do that given the comment 18 and that we only know of this affected website.

The server is perfectly well adjusted. Everything worked perfectly before. This bug has already been corrected after version 81.0 and before that in previous versions this bug has already been identified and then corrected. The script designer has sold thousands of scripts and all of them have the same problem, which obviously has nothing to do with server tuning. For your information, more than 5,000 commercialized sites are in this situation. Comments are posted here and the developer's response is indeed a bug to report at Mozilla. Cordially. https://codecanyon.net/item/wowonder-the-ultimate-php-social-network-platform/13785302

Flags: needinfo?(waxmax)

Hi Walter,
can you check if the php files in question contain only something like

header("Pragma: no-cache");

and not also

header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");

or similar? Then the software you are running on your server is not setting the headers in the expected way, assuming that you use the default settings for caching. So technically your server might be perfectly well adjusted but still send the wrong headers. In that case probably a bug should be filed against wowonder. Thank you

Flags: needinfo?(waxmax)

Changing severity to S3 because of comment 18, 19 and 21 that this is more likely due to sever configuration. Once we get the final confirmation from reporter, we may close this as invalid.

Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.