1636109 - 76.0 doesn't always resend the POST request body after Kerberos authentication

Status: RESOLVED DUPLICATE of bug 1696386

(Core :: Networking: HTTP, defect, P2)

Description

[oron]

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

Steps to reproduce:

I develop for an intranet application at work. It is based on ASP.NET Webforms. The production servers have IIS 7 with persistent authentication disabled (Persist-Auth: false), which means that the browser should re-authenticate on every request.

For a POST request (full PostBack) with a large enough body, Firefox does not resend the request body anymore as of Firefox 76 (worked with previous versions). I have verified this in Fiddler. Other browsers do not have this issue. This breaks the website because the ViewState is not being sent.

I was able to reproduce this issue when the POST body was about 1.5MB in size. It was consistent - small requests worked as expected while larger ones did not.

Actual results:

Incorrect behavior in Firefox 76:

• Browser sends the request (without authorization header)
• Server responds with 401
• Browser resends the request with an empty body, with authorization header
• Server waits for the body but does not receive it, and the request gets cancelled after 2 minutes. Eventually, the browser displays a 401 Not Authorized error, but with Fiddler running I can see a 408 error with the text: "The request body did not contain the specified number of bytes. Got 0, expected xxx."

Expected results:

Expected compliant behavior (Chrome does it like this):

• Browser sends the request (without authorization header)
• Server responds with 401
• Browser resends the same complete request, with authorization header
• Server responds with 200 + content

Comment 1

[Firefox Bug Husbandry Bot]

Because this bug's Severity is normal and has not been changed, and this bug's priority is -- (none,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 3

[Mike Taylor [:miketaylr]]

Hi Oron, would you be willing to help us pin down a regression range using https://mozilla.github.io/mozregression/? Feel free to email [e-mail] if you need instructions on how to use it (but the docs are pretty good).

Comment 4

[oron]

Sorry for the delay - I just tested with mozregression and found the following:

• Regression range: The best I could get was 2019-10-22 to 2019-11-29. The builds in between seem to be broken, I tested 12 builds between these dates, including 2019-10-23 and 2019-11-28, and they all crashed when I tried to reproduce the issue. With most the tab crashed, with the others the browser crashed with exit code 1.
  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=47d7c18620c845c3a42610fea5468ccc50889bae&tochange=b4b10ae558b9ca109218935d2bf48844cbfd7857

• The issue does not occur when manually authenticating with username and password - it only occurs with automatic authentication.
  I have the following non-default about:config options set when I reproduce the issue:
  network.automatic-ntlm-auth.allow-non-fqdn=true
  network.automatic-ntlm-auth.trusted-uris=<redacted>
  network.negotiate-auth.allow-non-fqdn=true
  network.negotiate-auth.delegation-uris=<redacted>
  network.negotiate-auth.trusted-uris=<redacted>

Comment 5

[Mike Taylor [:miketaylr]]

Thanks -- there's a lot going on in that range, but hopefully someone from the networking team can make sense of it. :)

Comment 6

[Valentin Gosu [:valentin] (he/him)]

I'm fairly sure we can dupe to bug 1696386