You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've just spent several hours battling a bizarre bug with a site I've just upgraded to .NET 8.
On submitting a long-ish form, the server would return a completely blank response with a status of 400.
With a bit of digging, I was able to confirm that this was caused by the anti-forgery validation failing. But there was no obvious reason, and no errors logged anywhere. Shorter versions of the same form worked flawlessly.
Eventually in desperation, I decided to try writing all of the form's keys to the debug window when the error was triggered. And suddenly: BOOM! "Form value count limit 1024 exceeded".
It seems like the anti-forgery validation code doesn't trigger the value count limit; it simply stops once it reaches the limit, and doesn't examine any more form values. And since the validation token field is at the bottom of the form, it sees a form submission without a validation token, which it rejects.
But this then leaves us with a request that was rejected, with no clue as to why it was rejected.
Personally, I think there are two possible ways to avoid this confusion.
Move the anti-forgery token field to the top of the form. That should let it past the anti-forgery validation to trigger the "value count" validation.
Make the "value count" validation run before the anti-forgery validation. If there are too many values in the form, then the chances are the anti-forgery validation is going to fail anyway.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I've just spent several hours battling a bizarre bug with a site I've just upgraded to .NET 8.
On submitting a long-ish form, the server would return a completely blank response with a status of
400
.With a bit of digging, I was able to confirm that this was caused by the anti-forgery validation failing. But there was no obvious reason, and no errors logged anywhere. Shorter versions of the same form worked flawlessly.
Eventually in desperation, I decided to try writing all of the form's keys to the debug window when the error was triggered. And suddenly: BOOM! "Form value count limit 1024 exceeded".
Once I configured the form options to increase that limit, the form started working again.
It seems like the anti-forgery validation code doesn't trigger the value count limit; it simply stops once it reaches the limit, and doesn't examine any more form values. And since the validation token field is at the bottom of the form, it sees a form submission without a validation token, which it rejects.
But this then leaves us with a request that was rejected, with no clue as to why it was rejected.
Personally, I think there are two possible ways to avoid this confusion.
Beta Was this translation helpful? Give feedback.
All reactions