Behavior is different to what is documented - IFormCollection.Item[String] Property

[The-Futurist]

Describe the bug

When porting old .NetF code we had to make changes because Request no longer has an indexer but instead exposes sub-properties that themselves have indexers.

During a test we attempt this:

        public void OnGet()
        {
            var a = NepHttpContext.Current;

            var x = a.Request.Form["LOGON_USER"];
        }

The code throws an exception yet it should either return the value or return StringValues.Empty or throw if the supplied key is null - according to the documentation.

Its seems that either the documentation is wrong or this is a bug.

To Reproduce

Just create a new empty .Net5 web app and then add the above code to the template code that's present in the project, as shown here:

namespace CoreWebApp.Pages
{
    public class IndexModel : PageModel
    {
        private readonly ILogger<IndexModel> _logger;

        public IndexModel(ILogger<IndexModel> logger)
        {
            _logger = logger;
        }

        public void OnGet()
        {
            var a = NepHttpContext.Current;

            var x = a.Request.Form["LOGON_USER"];
        }
    }
}

The NepHttpContext class is our own helper class, it just gets the current request.

Exceptions (if any)

Further technical details

• ASP.NET Core version
• Include the output of dotnet --info
• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version

App targets .Net5, using VS 2019, here's the donet info:

[davidfowl]

You can read form fields in a get request. It seems you're trying to replace the indexer which merged query and form I believe. That doesn't exist in ASP.NET Core. If you want to read the query string then use .Query and if you need to read the form you can use .Form but only when a form is actually being posted.

[The-Futurist]

You can read form fields in a get request. It seems you're trying to replace the indexer which merged query and form I believe. That doesn't exist in ASP.NET Core. If you want to read the query string then use .Query and if you need to read the form you can use .Form but only when a form is actually being posted.

Ahh, I see, OK so the entire scenario is invalid here, OK that makes sense this test is a bit contrived.

May I ask then, in old .NetF code we have this:

string tmpAuthIdentity = System.Web.HttpContext.Current.Request["LOGON_USER"];

I want to simply replace this with whatever is equivalent under ASP.NET Core, may articles talk about this being a server variable in older .NetF apps. So I don't know that this is anything in a form this was just an experiment (and we did not expect an exception).

The old ASP.NET documentation describes the indexer thus:

Gets the specified object from the QueryString, Form, Cookies, or ServerVariables collections.

It doesn't make it clear if a key could be present in each and if so, in what order it searches each of these.

The above .NetF code works fine, its part of a larger library we've had for years, I'm just trying to tweak the few areas of the code that are not compatible with .NetF.

Thanks for your prompt reply by the way @davidfowl

[The-Futurist]

By the way, if the access to Form["LOGON_USER"] is illegal because there is no form being posted, could the API not throw a better exception? with a message like "No form is present in this request" or something?

[davidfowl]

Seems like you're looking to read the server variables. This will only work on IIS. There's likely a modern alternative to this that doesn't require looking at this value.

You should be able to do this:

string tmpAuthIdentity  = NepHttpContext.Curent.GetServerVariable("LOGON_USER");

The modern alternative though is likely:

string tmpAuthIdentity = NepHttpContext.Current.User.Identity.Name;

[BrennanConroy]

Triage: IFormCollection.Item API should properly document the exception case(s), and mention the sync-over-async internal implementation detail. And make the error nicer like "No form found" etc.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.