"Null" string passed to controllers, despite option for custom null value

The Null value used for query parameters which are null option does not work for a parameter of type string.

I created a GET method with this signature, so I have a string, a DateTime? and a DateTime:

    public async Task<ActionResult<bool>> HasOauthMapping(string accessToken, DateTime nonNullableDate, DateTime? nullableDate)

The generated typescript (Angular) code is as follows (with "foo" used for the ‘substitute’ null value):

  if (accessToken !== undefined)
        url_ += "accessToken=" + encodeURIComponent("" + accessToken) + "&"; 

    if (nonNullableDate === null)
        throw new Error("The parameter 'nonNullableDate' cannot be null.");
    else if (nonNullableDate !== undefined)
        url_ += "nonNullableDate=" + encodeURIComponent(nonNullableDate ? "" + xnonNullableDate.toJSON() : "foo") + "&"; 

    if (nullableDate !== undefined)
        url_ += "nullableDate=" + encodeURIComponent(nullableDate ? "" + nullableDate.toJSON() : "foo") + "&"; 
    url_ = url_.replace(/[?&]$/, "");

As you can see the value "foo" is correctly substituted for both DateTime parameters but for a string parameter a null value gets converted to "" + null or the actual string "null".

I can pass undefined but I’d much prefer for the same logic to apply for all data types.

This is similar to this issue https://github.com/RSuter/NSwag/issues/1168

[adamjones1]

I would find it very useful if you could customise the “null string” that the Null value used for query parameters which are null promises to do, rather than have it hard-coded to "". In many situations the empty string is a perfectly valid input which is not semantically the same as null, and you need to be able to distinguish between the two. Or you may simply be attempting to connect with a service beyond your control which uses a different convention for representing nulls than this.

Common options include:

• The URL-encoded null value (/endpoint?foo=%00&bar=1);
• A parameter name without a value (/endpoint?foo&bar=1 - no equals sign)
• Using "" as you say (/endpoint?foo=&bar=1);
• And using a non-empty designated null string outside the space of valid input strings (/endpoint?foo=#NULL#&bar=1 if # is an illegal character, say)

APIs vary so support for any of these cases, not just the "" case, would be tremendous.

[RicoSuter]

I think we should send “” instead of “null” when passing a null parameter, right? “null” does not make sense in any case…