Content_Disposition should NOT be mandatory on Multipart

[andrieshiemstra]

This behaviour was added for issue https://github.com/actix/actix-web/issues/1947 and in PR https://github.com/actix/actix-web/pull/2451 or https://github.com/actix/actix-web/pull/2090 but i believe the claims about it being mandatory in the original issue are a misconception.

so since version 0.4.0-beta.8

see https://www.w3.org/Protocols/HTTP/Issues/content-disposition.txt

1.5  Content-Disposition and Multipart

   If a Content-Disposition header is used on a multipart body part, it
   applies to the multipart as a whole, not the individual subparts.
   The disposition types of the subparts do not need to be consulted
   until the multipart itself is presented.  When the multipart is
   displayed, then the dispositions of the subparts should be respected.

   If the `inline' disposition is used, the multipart should be
   displayed as normal; however, an `attachment' subpart should require
   action from the user to display.

   If the `attachment' disposition is used, presentation of the
   multipart should not proceed without explicit user action.  Once the
   user has chosen to display the multipart, the individual subpart
   dispositions should be consulted to determine how to present the
   subparts.

Although it may be needed on multipart/form-data (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition) I believe it is otherwise optional and protocols like MTOM seem to use it that way....

Expected Behaviour

multipart/related requests should be able to parse without a Content-Disposition header

Current Behaviour

Fails with "mp err NoContentDisposition"

Possible Solution

make multipart:Server:Field.cd an Option again

Steps to Reproduce (for bugs)

start SoapUI

• make a random request
• enable and force MTOM
• send request

request sample

POST http://myserver.local/webServiceEndpointTest HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: multipart/related; type="application/xop+xml"; start="<[email protected]>"; start-info="text/xml"; boundary="----=_Part_0_1662012483.1700221162492"
SOAPAction: "soapbodystufwithchildren"
MIME-Version: 1.0
Content-Length: 9370
Host: myserver.local
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/16.0.2)


------=_Part_0_1662012483.1700221162492
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: 8bit
Content-ID: <[email protected]>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<soapbodystufwithchildren />
</soapenv:Body>
</soapenv:Envelope>
------=_Part_0_1662012483.1700221162492--

error:

mp err NoContentDisposition

which originates i think from server.rs:352

let cd = if let Some(content_disposition) = content_disposition {
                content_disposition
            } else {
                return Poll::Ready(Some(Err(MultipartError::NoContentDisposition)));
            };

Context

can't make webservice endpoints when MTOM is used

• Actix Web Version: 4

[robjtede]

There's certainly some tension here between the permissiveness of actix-multipart when it comes to multipart content other than form-data and an easy-to-use API for the common case. Lemme have a think about this.

[andrieshiemstra]

Hi @robjtede , any updates on this? would you accept a PR making this optional again?

[andrieshiemstra]

Awesome! Thanks @robjtede !

[robjtede]

released in v0.7.0