Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content_Disposition should NOT be mandatory on Multipart #3193

Open
andrieshiemstra opened this issue Nov 17, 2023 · 1 comment
Open

Content_Disposition should NOT be mandatory on Multipart #3193

andrieshiemstra opened this issue Nov 17, 2023 · 1 comment
Labels
A-multipart project: actix-multipart needs-investigation

Comments

@andrieshiemstra
Copy link

This behaviour was added for issue #1947 and in PR #2451 or #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="<rootpart@soapui.org>"; 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: <rootpart@soapui.org>

<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 robjtede added needs-investigation A-multipart project: actix-multipart labels Nov 17, 2023
@robjtede
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-multipart project: actix-multipart needs-investigation
Projects
None yet
Development

No branches or pull requests

2 participants