Avoid computing `FormFeature` when calling `HttpRequest.HasFormContentType`

[captainsafia]

Currently, invoking the HttpRequest.HasFormContentType property will implicitly compute a FormFeature and use use that to compute whether the content type is form-related:

aspnetcore/src/Http/Http/src/Internal/DefaultHttpRequest.cs

Lines 150 to 153 in 76d2fda

	public override bool HasFormContentType
	{
	get { return FormFeature.HasFormContentType; }
	}

We should consider updating this implementation such that it checks the content-type directly instead of allocating a feature.

cc: @davidfowl @Tratcher

[Tratcher]

Just make sure the checks are consistent/equivalent. E.g. the alternative check you added in another recent PR was simplified for perf reasons and won't always return the same result.

[captainsafia]

Just make sure the checks are consistent/equivalent. E.g. the alternative check you added in another recent PR was simplified for perf reasons and won't always return the same result.

Correct. I'd personally be fine with just calling these methods directly as a step towards optimization here.

[davidfowl]

I think we'd want to do a couple of investigations:

• Avoid allocating the MediaTypeHeader (see https://github.com/dotnet/aspnetcore/blob/376b6b0c860f113d59cf3e82677d7f8a6e674716/src/Mvc/Mvc.Core/src/Formatters/MediaType.cs)
• Avoid allocating the form feature if there isn't one already.
• This antiforgery check seems to happen when reading the form (

  aspnetcore/src/Http/Http/src/Features/FormFeature.cs

  Line 77 in 376b6b0

  if (Form != null)

  ), which happens when you check the content type. This seems wrong.