Storage erroneously looks for Content-Disposition as a request header

[SandGrainOne]

Description

Storage has the same issue as the app lib logic described in issue Altinn/app-lib-dotnet#96. Content-Disposition should not appear as a request header. This should to be fixed.

Initial analysis indicate that a valid multipart request will work. Storage should be able to handle valid requests without any additional changes. This issue is primarily for cleaning up what would otherwise be dead code.

The bug is found in the DataController class in method ReadRequestAndCreateDataElementAsync.

Additional Information

No response

Tasks

• Identify all cases where Storage expect to find Content-Disposition in a request header.
• Rewrite the incorrect logic.
• Write unit tests.

Acceptance Criterias

• DataController doesn't accept requests where Content-Disposition as a request header.
• DataController is able to identify the filename and file size from Content-Disposition as a section header.

[tjololo]

After further investigation it seems like Content-Disposition will be present in the Requests headers when the HttpClient uploads a binary attachment through ByteArrayContent or StreamContent.
Logged all headers in the apps controller and wrote a client for uploading a xml and pdf.
Client code:

public async Task<string> ProcessUploadXml(string instanceId, byte[] attachment, string filename, CancellationToken ct)
{
    var uri = $"{_baseUri}/{_appUri}/instances/501337/{instanceId}/data?dataType=attachment";
    using (var content = new StreamContent(new MemoryStream(attachment)))
    {
        content.Headers.ContentType = new MediaTypeHeaderValue("application/xml");
        content.Headers.ContentDisposition = ContentDispositionHeaderValue.Parse($"attachment; filename=\"{filename}\"");
        var httppRequest = new HttpRequestMessage(HttpMethod.Post, uri);
        httppRequest.Content = content;
        var res = await _client.SendAsync(httppRequest);
        if (!res.IsSuccessStatusCode)
        {
            _logger.LogError("Upload to {URI} failed with statuscode: {StatusCode} content: {Response}", uri,res.StatusCode, await res.Content.ReadAsStringAsync());
            throw new Exception("upload failed");
        }

        var responseConrtent = await res.Content.ReadAsStringAsync();
        return responseConrtent;
    }
}

Headers logged on the server side was:

      Connection: close
      Host: local.altinn.cloud
      Authorization: Bearer ##omitted##
      Content-Type: application/xml
      Content-Length: 33
      X-Real-IP: 172.18.0.1
      X-Forwarded-For: 172.18.0.1
      Content-Disposition: attachment; filename="demo.xml"

As this is how HttpClient sets header when setting content.Headers.ContentDisposition on StreamContent and other I think we should keep the logic as it is today in storage