Closed Bug 1302717 Opened 8 years ago Closed 8 years ago

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

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Version:
51 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1293765
Tracking Flags:
Tracking Status
firefox48 --- unaffected
firefox49 --- unaffected
firefox50 - fixed
firefox51 --- unaffected

People

(Reporter: kats, Unassigned)

References

(
URL
)

Details

(Keywords: dataloss, regression) 

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
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.
URL: https://staktrace.com/pub/bug1302717/...
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: → 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
Closed: 8 years ago
Flags: needinfo?(honzab.moz)
Resolution: --- → DUPLICATE
No longer depends on: 1293765
You need to log in before you can comment on or make changes to this bug.