[jyotir-aditya]

splitChallenges rescanned the rest of the header after every comma, so parsing took quadratic time (100 KB of commas: 5.7 s on main). The lookahead is now computed once per run of commas and blanks, and startsWithAuthParam reads only the next token.

Output is unchanged except for one case: a comma inside the name before the = (for example x, a,b=c) now ends the challenge. A token cannot contain a comma (RFC 9110, section 5.6.2); before, a,b was taken as a parameter name.

Tests

• TestSplitChallenges: cases for params-less challenges, a blank before =, whitespace inside the name, a non-blank space before =, and the comma case above. All but the comma case pass on the old code, so they pin existing behavior.
• TestParseWWWAuthenticateLinearTime: a 100 KB run of commas must parse within 2 s. The old code takes about 5.7 s and fails; the new code takes well under 100 ms. The input is deliberately small so the test adds little load to the parallel mcp tests.
• I also compared the new splitChallenges with the old one on 3,000,000 random headers (scratch test, not included): they differ only by the comma rule.
• gofmt -l ., go vet ./..., go test ./... and go test -race ./oauthex are clean. I did not run the conformance scripts; the change does not touch protocol behavior.

Fixes #1455

[jyotir-aditya]

The race-test job failed on TestResourceSubscriptions_InMemory (mcp_test.go:3074: timed out waiting for resource update), in a package this PR doesn't touch. That test is flaky on its own: on unmodified main (2e00768), go test -race -cpu=2 ./mcp -run '^TestResourceSubscriptions_InMemory$' -count=300 failed 2 times in 300 runs.

My original timing test did make it fail more often, though. It ran five 200 KB inputs in parallel with the mcp tests, and in a controlled A/B (2 cores, -race, 900 runs each) the flake fired 39 times on this branch against 1-3 times on main. I've replaced it with a single 100 KB input that takes well under 100 ms. With that version the same setup gives 4 against 3 on main, which is no difference. The new commit only changes that test; the fix itself is unchanged.

Could a maintainer re-run the failed job? I can't.

[guglielmo-san]

@jyotir-aditya thank you for the contribution!