1940594 - discussions.apple.com - Unable to get past the "choose a username" screen (because the site's dynamic requests to Apple's username-validation service fail with status 422 Unprocessable Entity) [nightly-only]

Status: NEW

(Web Compatibility :: Site Reports, defect, P1)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Have an Apple ID which you've never previously used to post on discussions.apple.com.
2. Visit https://discussions.apple.com and click "Sign in", and enter your Apple ID credentials.
3. Hopefully you'll get to a page that says:

Welcome to Apple Support Communities
Create your Communities username

4. Type in some username, e.g. just the word "example" (which happens to already be taken), and see how the page changes.
5. Add 3 random numbers as a suffix, e.g. "951", and see how the page changes.

EXPECTED RESULTS:
In step 4, the page should show a message saying "That username is taken."
In step 5, the "Continue" button should become enabled so that you could proceed if you wanted to.

ACTUAL RESULTS:
The validation doesn't work at all.
In step 4, the page doesn't tell me that "example" is already taken.
In step 5, the page never enables the "Continue" button.
If I open the DevTools Network pane, I see that each keystroke results in a request to https://discussions.apple.com/signup/validate which fails with status 422 Unprocessable Entity.

Comment 1

[Daniel Holbert [:dholbert]]

Chrome 133.0.6905.0 (Official Build) dev (64-bit) gives EXPECTED RESULTS.
Firefox Nightly 136.0a1 (2025-01-07) gives ACTUAL RRSULTS.

(In reply to Daniel Holbert [:dholbert] from comment #0)

If I open the DevTools Network pane, I see that each keystroke results in a request to https://discussions.apple.com/signup/validate which fails with status 422 Unprocessable Entity.

Actually -- in Chrome, these per-keystroke network requests also fail with status 400 Bad Request, so they might be unrelated to the actual functional problem here that I'm seeing in the web page. [EDIT: Actually-actually, the status is the key thing here; see comment 5.]

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug (first actual-results in Firefox, then expected-results in Chrome)

Comment 3

[Daniel Holbert [:dholbert]]

Nightly 2024-01-01 gives me EXPECTED RESULTS, so this is a regression. I'll try to track down a regression range.

Comment 4

[Daniel Holbert [:dholbert]]

regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9f320b922295e3181fccd4484ba364af9d1fcb32&tochange=a90576b7f21bf39c58ef23d3de5b9b2acc6275c6

--> regression from bug 1830022. smayya, could you take a look?

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #1)

Actually -- in Chrome, these per-keystroke network requests also fail with status 400 Bad Request, so they might be unrelated to the actual functional problem here that I'm seeing in the web page.

Aha, some corrections here, testing a bit more in Chrome:

• The 400 Bad Request response seems to actually be the way that the server indicates "sorry, that username is taken"
• If I type a username that's not-taken (e.g. example951), then the network request comes back with status 200.
• So presumably that status is what the page uses as a signal to decide whether to show the "That username is taken." message vs. un-hide the Continue button.

Firefox Nightly from before the regression shows the same results as Chrome in the DevTools network panel, too -- the per-keystroke requests come back with status 400 if the username is taken vs 200 if it's not taken.

It's only in recent Nightlies (after the regression) that these requests all have status 422.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: screencast showing validation responses (400/200 before regression, vs 422 after regression)

Here's a screencast with Network DevTools open, showing what happens when I type various usernames/partial-usernames and let the site attempt to validate them.

Left side of the screencast is Firefox Nightly from before-the-regression, and its network requests to the "validate" URI come back with status 400 / 200 depending on whether the username is available.

Right side of the screencast is current Nightly, and its network requests to that same "validate" URI come back with status 422 regardless of username availability.

Comment 7

[Daniel Holbert [:dholbert]]

Aha, looking at the regression patch-stack a bit more, I see that this is behind about:config pref network.http.idempotencyKey.enabled. If I set that to false, then this starts working as-expected (no reload needed; the next thing I type into the username field gets properly validated).

network.http.idempotencyKey.enabled is only enabled-by-default in Nightly configs for the time being (with value: @IS_NIGHTLY_BUILD@ here), so that means we can consider this "disabled" for the 135 release, and it'll be disabled for all subsequent release versions as they move off of Nightly.

Comment 8

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

Set release status flags based on info from the regressing bug 1830022

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #7)

Aha, looking at the regression patch-stack a bit more, I see that this is behind about:config pref network.http.idempotencyKey.enabled. If I set that to false, then this starts working as-expected (no reload needed; the next thing I type into the username field gets properly validated).

I compared "copy-as-curl" results for the request here, with this pref enabled (broken) vs. disabled (working), and made the following observations:

• The only difference is the presence of a header like this:

-H 'Idempotency-Key: "13448575235753409992"'

• (There are also expected/irrelevant-looking differences in (encrypted/encoded) data-raw, X-Signature, and X-Request-Time fields.)
• The Idempotency-Key value (shown above) is notably enclosed in double-quotes, and I'm guessing maybe it's not supposed to be... None of the other fields have double-quotes around their value like that, including string-valued ones. They look like this (note the single-quote around the key+value, but no additional quotes around the value):

-H 'Accept-Encoding: gzip, deflate, br, zstd' \
-H 'X-Request-Time: 1736786129843' \

So I'm suspicious that these double-quotes are accidental, and Apple's rejecting the request because these double-quotes make it invalid in some way. I just tested a local build where I removed them, and that gave me EXPECTED RESULTS, so I think maybe that's the right fix.

I'll spin off a helper bug to post that patch.

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #9)

• The Idempotency-Key value (shown above) is notably enclosed in double-quotes [...]
  So I'm suspicious that these double-quotes are accidental, and Apple's rejecting the request because these double-quotes make it invalid in some way. I just tested a local build where I removed them, and that gave me EXPECTED RESULTS, so I think maybe that's the right fix.

I spun off bug 1941375 for this, but valentin noted there (in bug 1941375 comment 3) that the RFC does actually require these double-quotes for this particular HTTP header. So, Firefox is correct here, and the server is mistakenly choking on the value. I think it's a bit rare for HTTP headers to have double-quotes like this, so I would guess the discussions.apple.com web-server is just doing some rudimentary server-side validation of the headers, which is choking on the double-quote character and (incorrectly) rejecting the whole request as being malformed.

Right now Firefox Nightly is the only browser to have this Idempotency-Key HTTP header implemented, I think (behind about:config pref network.http.idempotencyKey.enabled as noted above), which is why we're hitting this and other browsers are not.

karlcow: could you help us get in touch with the people at Apple who run the https://discussions.apple.com/signup/validate validation endpoint (or the discussions.apple.com forum in general)? It seems they've got some broken http-header validation code that's preventing us from shipping support for this new http header. Thanks!

Comment 11

[Daniel Holbert [:dholbert]]

To be clear, I don't imagine discussions.apple.com cares about Idempotency-Key at all right now. But presumably there's some logic at https://discussions.apple.com/signup/validate that complains (and returns 422 Unprocessable Entity) if any http header includes a double-quote character.

Comment 12

[Karl Dubost💡 :karlcow]

Reported to Apple at rdar://142843628

Daniel, Thanks a lot for the super nice diagnosis.

Comment 13

[Sunil Mayya]

(In reply to Daniel Holbert [:dholbert] from comment #11)

To be clear, I don't imagine discussions.apple.com cares about Idempotency-Key at all right now. But presumably there's some logic at https://discussions.apple.com/signup/validate that complains (and returns 422 Unprocessable Entity) if any http header includes a double-quote character.

Thanks Daniel for Bouncing on this. I agree with the above analysis.
I tested with a non-string value for a random header and it returns DOES not complain. Problem is when we are using string-based value for the header.

We dont see this issue with other apple websites like https://supportmetrics.apple.com/content/services/stats.
As valentin mentioned we are the first browser to have implemented this change and someone from discussions.apple.com should confirm their issue related to string processing

Comment 15

[Dianna Smith [:diannaS]]

Marking as disabled since 139 is in beta and network.http.idempotencyKey.enabled is nightly only

Comment 16

[Valentin Gosu [:valentin]]

I just checked and was able to login to discussions.apple.com using my password and yubikey. (Nighlty 144)
Can you still reproduce this?

Comment 17

[Daniel Holbert [:dholbert]]

I can still reproduce. The issue isn't about being unable to login; it's that they're not able to notify you that a candidate username is already taken, when you choose your username for discussions.apple.com.

Note in comment 0 actual-results:

In step 4, the page doesn't tell me that "example" is already taken.

Comment 18

[Daniel Holbert [:dholbert]]

(When I get to the "Create your communities username" part of the STR, and I type in "example": in Chrome, the page still correctly notifies me "That username is taken", while in Firefox, it shows a green checkmark as if the username were available)

Comment 19

[Daniel Holbert [:dholbert]]

(In reply to Karl Dubost💡 :karlcow from comment #12)

Reported to Apple at rdar://142843628

Hi Karlcow! Is there any update on this? I just retested and confirmed I'm still seeing the issue here.

(The header in question is currently only present in Firefox Nightly, though I think we're exploring getting it shipped to release, per recent activity in bug 1991641.)

Comment 21

[Daniel Holbert [:dholbert]]

Further note: we've now learned that this issue also prevents users from posting on discussions.apple.com (though they can edit their earlier posts). See bug 1999667 (particularly bug 1999667 comment 8) for notes/details on that.

(Presumably discussions.apple.com uses the same HTTP-header-parsing/validation logic in both of these cases -- for username-availability checking [this bug] and also for one of the http-requests involved in making posts [bug 1999667]. So both workflows are broken if this Idempotency-Key: "[something]" header is present -- likely due to the server choking on the double-quoted string, per comment 10.)