[
https://issues.apache.org/jira/browse/CXF-9111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18046323#comment-18046323
]
Tom Besnard commented on CXF-9111:
----------------------------------
hi,
Since this [change
|https://github.com/apache/cxf/commit/a174014a9ea64dae8412ead69499db585189ac8c]that
adds the {{Content-Disposition}} header by default, we are experiencing some
regressions in our {{multipart/form-data}} calls.
We manually add the {{Content-Disposition}} with a filename, and it is now
being overwritten without the filename.
Our attachment creation :
{code:java}
new AttachmentBuilder()
.id("content")
.mediaType(MediaType.APPLICATION_OCTET_STREAM)
.header(HttpHeaders.CONTENT_DISPOSITION, "form-data;
name=\"content\"; filename=\"content.txt\"")
.object("content".getBytes())
.build() {code}
4.0.10
{code:java}
Content-Disposition: form-data;name="content"{code}
4.0.9
{code:java}
Content-Disposition: form-data; name="content"; filename="content.txt"{code}
Would it be possible not to modify the header if it is already present ?
{code:java}
if (MediaType.MULTIPART_FORM_DATA_TYPE.isCompatible(mediaType) &&
att.getHeader("Content-Disposition") == null) {
ContentDisposition cd = new ContentDisposition("form-data;name=\"" +
att.getContentId() + "\"");
MultivaluedMap<String, String> newHeaders = new
MetadataMap<>(att.getHeaders(), false, true);
newHeaders.putSingle("Content-Disposition", cd.toString());
ret = new Attachment(att.getContentId(), dh, newHeaders);
} {code}
Tom.
> Default behavior for "multipart/form-data" requests not standard-conform
> ------------------------------------------------------------------------
>
> Key: CXF-9111
> URL: https://issues.apache.org/jira/browse/CXF-9111
> Project: CXF
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Christian Mattar
> Assignee: Freeman Yue Fang
> Priority: Major
>
> We are using a client interface like this:
> {noformat}
> @POST
> @Path("/checkMultipartAsAttachment")
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> void checkMultipartAsObject(@Multipart(value = "part1", type =
> MediaType.APPLICATION_JSON) JsonData part1, @Multipart(value = "part1", type
> = MediaType.APPLICATION_JSON) JsonData part2);{noformat}
>
> However, the multiparts are not recognized by e.g. Spring MVC. When
> inspecting the internal CXF data structures, I can see that the generated
> Attachment objects have no Content-Disposition header, and thus, no
> Content-Disposition header is sent through the wire.
> Instead, a "Content-ID" header is sent. This header is also picked up by CXF
> on server-side, so CXF->CXF communication works.
> As far as I can tell, the currently generated request is not valid for MIME
> type "multipart/form-data" according to the relevant
> https://datatracker.ietf.org/doc/html/rfc7578 .
> (it might by valid for MIME type "multipart/related" according to
> https://www.ietf.org/rfc/rfc2387.txt)
> The same holds true by default for requests like this:
>
> {noformat}
> @POST
> @Path("/checkMultipartAsAttachment")
> @Consumes(MediaType.MULTIPART_FORM_DATA)
> void checkMultipartAsAttachment(Attachment multipart);
> {noformat}
> However, in these cases we could at least add the Content-Disposition Header
> to the Attachment-object in our own code.
> It would be great if by default, requests for "multipart/form-data" would be
> standards-conform.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
