HttpClient: Consider removing MailAddressParser

[geoffkizer]

This parser is used for the From header, which is an uncommon HTTP header.

This class contains a lot of complicated logic, and contributes in a nontrivial way to Blazor assembly size. See discussion here: #44534 (comment)

Unlike most parsers, this parser does not produce a strongly-typed value -- it just validates the mail address and returns it as a string.

We should consider just removing this entirely. This would help Blazor assembly size, and keep consistency between full framework and Blazor.

The impact of removing this would be that From header values that were previously considered invalid, and thus were either discarded or caused exceptions, would now be considered valid. Given that the From header is not commonly used, and only error cases are affected, I don't think this is a problem.

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This parser is used for the From header, which is an uncommon HTTP header.

This class contains a lot of complicated logic, and contributes in a nontrivial way to Blazor assembly size. See discussion here: #44534 (comment)

Unlike most parsers, this parser does not produce a strongly-typed value -- it just validates the mail address and returns it as a string.

We should consider just removing this entirely. This would help Blazor assembly size, and keep consistency between full framework and Blazor.

The impact of removing this would be that From header values that were previously considered invalid, and thus were either discarded or caused exceptions, would now be considered valid. Given that the From header is not commonly used, and only error cases are affected, I don't think this is a problem.

Author:	geoffkizer
Assignees:	-
Labels:	area-System.Net.Http, untriaged
Milestone:	-

[KevinCathcart]

I am very skeptical that this has ever provided meaningful value. That header is both rare, and so completely unimportant, that even when the header is supplied this validation is probably just pointlessly wasting CPU cycles.

Sure, it could theoretically catch a bug in a crawler that sends a malformed address, but does anyone really care? The only thing I can realistically see any server bothering to do with that header is log it. I'd wager most server implementations make no effort to validate it, and in the unlikely event a server cared enough to validate, the user of the client would see the "400 Bad Request" error that said server should return for header validation failure, and the body of the response should explain what it objected to. That is the same sort of error they would get for any server side parsing error of an obscure or custom header HttpClient does not know about.

And if the server was returning that header, it is even less important to validate it as that is so non-standard that no client is even going to bother checking for it, much less use it for anything.

Tagging subscribers to 'size-reduction': @eerhardt, @SamMonoRT, @marek-safar, @CoffeeFlux
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This parser is used for the From header, which is an uncommon HTTP header.

This class contains a lot of complicated logic, and contributes in a nontrivial way to Blazor assembly size. See discussion here: #44534 (comment)

Unlike most parsers, this parser does not produce a strongly-typed value -- it just validates the mail address and returns it as a string.

We should consider just removing this entirely. This would help Blazor assembly size, and keep consistency between full framework and Blazor.

The impact of removing this would be that From header values that were previously considered invalid, and thus were either discarded or caused exceptions, would now be considered valid. Given that the From header is not commonly used, and only error cases are affected, I don't think this is a problem.

Author:	geoffkizer
Assignees:	-
Labels:	area-System.Net.Http, size-reduction, untriaged
Milestone:	-

[geoffkizer]

@dotnet/ncl Any objections?

[wfurt]

no. I do agree that the parsing has little value.