You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
let cd = ifletSome(content_disposition) = content_disposition {
content_disposition
}else{returnPoll::Ready(Some(Err(MultipartError::NoContentDisposition)));};
Context
can't make webservice endpoints when MTOM is used
Actix Web Version: 4
The text was updated successfully, but these errors were encountered:
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.
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
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
request sample
error:
which originates i think from server.rs:352
Context
can't make webservice endpoints when MTOM is used
The text was updated successfully, but these errors were encountered: