If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

HTTP auth credentials timeout of 5 minutes causes POST data to be dropped, resulting in XHR and form submission failures

RESOLVED DUPLICATE of bug 1293765

Status

()

Core
Networking: HTTP
RESOLVED DUPLICATE of bug 1293765
a year ago
a year ago

People

(Reporter: kats, Unassigned)

Tracking

({dataloss, regression})

51 Branch
dataloss, regression
Points:
---

Firefox Tracking Flags

(firefox48 unaffected, firefox49 unaffected, firefox50- fixed, firefox51 unaffected)

Details

(URL)

Lately (probably for around a month or so) I've been getting a lot of errors and wonky behaviour on my custom bugmail dashboard. Often XHR requests error out, and form submissions seem to have no effect (I consider this dataloss, because I lose changes that should have been made, but with no indication that something went wrong). Looking at my server side logs it looks like Firefox is often sending requests without the HTTP auth credentials and so getting 401 responses back. I suspect this might be the cause of the problem. Filing this bug as a placeholder while I try to narrow down the problem, maybe somebody else already filed something and this can be duped over.
Based on the server logs it looks like after ~5 minutes Firefox decides to not use the HTTP auth credentials and so the next request it makes gets a 401 back. It then resends the request with the auth credentials, and gets a 200 back, but maybe that re-send doesn't have the postdata, or something, because it seems to have no effect.

kats@madison https$ grep 401 access.log
24.141.32.151 - - [14/Sep/2016:03:33:28 -0700] "GET /apps/bugmash/dashboard.php HTTP/1.1" 401 8131 "-" "Mozilla/5.0 (Android 6.0.1; Mobile; rv:51.0) Gecko/51.0 Firefox/51.0"
24.141.32.151 - - [14/Sep/2016:03:38:43 -0700] "POST /apps/bugmash/wipe.php HTTP/1.1" 401 5084 "https://staktrace.com/apps/bugmash/dashboard.php" "Mozilla/5.0 (Android 6.0.1; Mobile; rv:51.0) Gecko/51.0 Firefox/51.0"
24.141.32.151 - - [14/Sep/2016:03:44:47 -0700] "POST /apps/bugmash/wipe.php HTTP/1.1" 401 8131 "https://staktrace.com/apps/bugmash/dashboard.php" "Mozilla/5.0 (Android 6.0.1; Mobile; rv:51.0) Gecko/51.0 Firefox/51.0"
24.141.32.151 - - [14/Sep/2016:03:50:07 -0700] "POST /apps/bugmash/wipe.php HTTP/1.1" 401 8131 "https://staktrace.com/apps/bugmash/dashboard.php" "Mozilla/5.0 (Android 6.0.1; Mobile; rv:51.0) Gecko/51.0 Firefox/51.0"
I'm definitely seeing this in Nightly 51 and Aurora 50, not sure yet if it affects Beta too.

[Tracking Requested - why for this release]:
Seems like a regression from previous behaviour that is potentially web-breaking for sites that use HTTP auth.
status-firefox48: --- → ?
status-firefox49: --- → ?
status-firefox50: --- → affected
tracking-firefox50: --- → ?
It looks like the 5 minute timeout is "normal" behaviour, because I see it across all channels (48, 49, 50, 51). However losing the postdata seems to be a regression in 50. In 49 beta when Firefox gets the 401 and resends the request with HTTP auth credentials, the request seems to work as intended. In 50 it does not.
status-firefox48: ? → unaffected
status-firefox49: ? → unaffected
Keywords: regression
Summary: HTTP auth credentials sporadically not sent, possibly related to XHR and form submission failures → HTTP auth credentials timeout of 5 minutes causes POST data to be dropped, resulting in XHR and form submission failures
(Reporter)

Comment 4

a year ago
STR
I managed to make a reduced test case, see URL. If you load the page and wait 5 minutes (until 6 result lines are shown) you'll see the 6th one showing failure.

After updating to the latest Aurora/Nightly builds I can repro the failure on the reduced test case in Aurora but not Nightly. Maybe it's been fixed, or maybe there's more than one issue. I'll see I can still repro other problems on Nightly.
status-firefox51: affected → unaffected
Can't repro any issues on Nightly any more, I guess my Nightly builds were just out-of-date and this was fixed recently. Whatever fixed it still needs uplifting to aurora though.
Andrei, can you please try to bisect what fixed this?
Flags: needinfo?(andrei.vaida)
As far as I can tell from the description and the versions affected, it might be related or the same as bug 1293628
See Also: → bug 1293628
I used mozregression to chase down the fix window. It narrowed it down to [1] from which bug 1293765 sounds appropriate - this is probably a dupe of that bug. Honza, are you intending to uplift bug 1293765 to 50?

[1] https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9b38b8ba8f9c82cc96a401e7ad9b4cc6ba54ad58&tochange=8cc4907776c85b5f57c1778bdd5b2a4ad8eb8055
Depends on: 1293765
Flags: needinfo?(andrei.vaida) → needinfo?(honzab.moz)
Bug 1293765 needs an uplift to 50 (m-b), yes.
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(honzab.moz)
Resolution: --- → DUPLICATE
Duplicate of bug: 1293765
No longer depends on: 1293765
No need to track this one, it got fixed in 50 in bug 1293765.
status-firefox50: affected → fixed
tracking-firefox50: ? → -
You need to log in before you can comment on or make changes to this bug.