`CreatedResult` should accept null location

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

RFC7231 suggests that the Location header is optional for 201 Created response.

The primary resource created by the request is identified by either a Location header field in the response or, if no Location field is received, by the effective request URI.

However, currently the constructors of CreateResult throws if null is passed to location, and ControllerBase.Created() throws if null is passed to url.

Expected Behavior

A response of 201 Created without Location header is created.

Steps To Reproduce

[HttpPost]
public ActionResult Create()
{
    return new CreatedResult((string?)null, null); // throws ArgumentNullException
}

[HttpPost]
public ActionResult Create()
{
    return Created((string?)null, null) // throws ArgumentNullException
}

Exceptions (if any)

System.ArgumentNullException: Value cannot be null. (Parameter 'location')
   at Microsoft.AspNetCore.Mvc.CreatedResult..ctor(String location, Object value)
   ...

.NET Version

6.0.101

Anything else?

No response

[khellang]

It’s too bad that uri is before value already, but I don’t think omitting a preceding parameter in one (or some) overloads is as bad as changing order between overloads (with same or more parameters).

you’d need either (string?)null or (Uri?)null to select the right overload.

The fact that there’s two overloads makes it even more compelling to add a single-parameter overload, since you need those ugly (string?)null casts everywhere to avoid ambiguity 😞

[halter73]

The approved API does not remove any constructors or methods. It merely changes the nullability annotations of some parameters.

If you need to remove test cases for them to compile or pass, that’s an indication of a breaking change which we will not accept.

❌ DISALLOWED: Renaming or removing a public member or parameter

This breaks all code that uses the renamed or removed member, or parameter.

It’s important that developers can confidently upgrade between versions of ASP.NET Core without updating a bunch of code. This sometimes means saying no to cleaning up APIs that are good enough because doing so would break already working applications.

When I test like below it works.

[HttpPost]
public ActionResult Create()
{
    return new CreatedResult(null, "Test");
}

I recommend using markdown for code snippets so we can search the content and more easily quote it.

This can only work because of the breaking change. This won’t compile with the approved changes. You’ll get the same error demonstrated by the sharplab.io sample I posted in my last comment on this issue. The following will compile though without warnings and work.

[HttpPost]
public ActionResult Create()
{
    return new CreatedResult((string?)null, "Test");
}

Currently, this would give nullability warnings and throw an ArgumentNullException at runtime.