[FromForm] and lists are not serialized correctly?
See original GitHub issuePlease see this stackoverflow post: https://stackoverflow.com/questions/55452461/a-list-of-guids-is-empty-when-passed-into-a-model-which-is-used-by-fromform-in
A short summary:
When using the default swagger configuration with a newly created ASP.NET Core 2.2 project and the following code, a [FromForm]
model that contains a list will not be filled correctly.
A list of strings will contain 1 value that contains all values passed, but seperated by a comma.
I expect these things to be turned into a list containing x values?
Controller:
[HttpPost("bug")]
public ActionResult<string> Bug([FromForm] BugModel bugModel)
{
var message = GetMessage(bugModel);
return Ok(message);
}
Model:
public class BugModel
{
/// <summary>
/// If you send a GUID it will not appear in this list
/// </summary>
public IEnumerable<Guid> Ids { get; set; }
/// <summary>
/// If you send 3 strings, the list will contain 1 entry with the 3 string comma separated.
/// </summary>
public IEnumerable<string> IdsAsStringList { get; set; }
}
Swagger will, with some input values, generate the following CURL statement:
curl -X POST "https://localhost:5001/api/Bug/bug" -H "accept: text/plain" -H "Content-Type: multipart/form-data" -F "Ids="9dfb212a-a215-4991-9452-3ddf90e21ec0","9dfb212a-a215-4991-9452-3ddf90e21ec0"" -F "IdsAsStringList="9dfb212a-a215-4991-9452-3ddf90e21ec0","9dfb212a-a215-4991-9452-3ddf90e21ec0""
But this is wrong, at least for a default generated ASP.NET Core 2.2 project.
The following CURL statement, which has duplicate Ids
fields, DOES work:
curl -X POST "https://localhost:5001/api/Bug/bug" -H "accept: text/plain" -H "Content-Type: multipart/form-data" -F "Ids="9dfb212a-a215-4991-9452-3ddf90e21ec0"" -F "Ids="9dfb212a-a215-4991-9452-3ddf90e21ec0"" -F "IdsAsStringList="9dfb212a-a215-4991-9452-3ddf90e21ec0","9dfb212a-a215-4991-9452-3ddf90e21ec0""
Issue Analytics
- State:
- Created 4 years ago
- Comments:9 (3 by maintainers)
Need fix for this bug
We’ve just encountered this issue. We had to do a workaround like below, but of course this is not usable as every API generation will override this.