Form extractor should return 422 Unprocessable Entity for deserialization errors

[connec]

• I have looked for existing issues (including closed) about this

Feature Request

Motivation

I noticed this when upgrading a project from axum 0.5 to 0.6, which led to some failing tests of invalid form data: deserialization errors from the Form extractor now convert into 400 Bad Request responses, when previously they were 422 Unprocessable Entity responses. Per the semantics discussed in #1378 it seems like 422 Unprocessable Entity would be the more appropriate response for syntactically valid form data that could not be deserialized.

Proposal

From doing some digging around, it looks like this change occurred to fix #1378. At that time, the rejection for a Form deserialization error was also FailedToDeserializeQueryString:

axum/axum/src/extract/rejection.rs

Lines 141 to 151 in 74105fc

	composite_rejection! {
	/// Rejection used for [`Form`](super::Form).
	///
	/// Contains one variant for each way the [`Form`](super::Form) extractor
	/// can fail.
	pub enum FormRejection {
	InvalidFormContentType,
	FailedToDeserializeQueryString,
	BytesRejection,
	}
	}

Later, in #1496, Form gets a dedicated FailedToDeserializeForm variant:

axum/axum/src/extract/rejection.rs

Lines 99 to 109 in 351df64

	composite_rejection! {
	/// Rejection used for [`Form`](super::Form).
	///
	/// Contains one variant for each way the [`Form`](super::Form) extractor
	/// can fail.
	pub enum FormRejection {
	InvalidFormContentType,
	FailedToDeserializeForm,
	BytesRejection,
	}
	}

However, this rejection is still set to return a 400 Bad Request:

axum/axum/src/extract/rejection.rs

Lines 73 to 79 in 211de92

	define_rejection! {
	#[status = BAD_REQUEST]
	#[body = "Failed to deserialize form"]
	/// Rejection type used if the [`Form`](super::Form) extractor is unable to
	/// deserialize the form into the target type.
	pub struct FailedToDeserializeForm(Error);
	}

Since the Form and Query extractors now have dedicated rejection types, it seems we could simply update the status for FailedToDeserializeForm to UNPROCESSABLE_ENTITY without disturbing the original fix in #1378. I'd be happy to make that PR if it's desirable and I'm not missing anything. This would be a breaking change (assuming the rejection statuses are covered by the versioning policy, and this isn't considered a bug).

[davidpdrsn]

That makes sense! Its just an oversight. We don't consider changing rejection statuses breaking changes so you're very welcome to submit a PR.