https://bz.apache.org/bugzilla/show_bug.cgi?id=67626
Bug ID: 67626
Summary: multipart request parts require Content-Disposition:
form-data, even when another multipart-subtype is used
Product: Tomcat 10
Version: 10.1.12
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: hans.ris...@data-experts.de
Target Milestone: ------
## Context
I am using Tomcat 10.1.12 through Spring-Boot 3.1.3 and have implemented an
endpoint for a multipart/mixed upload with one file part and 3 related parts
that contain json-based metadata accompanying the file.
## Problem
When trying to test this endpoint, I have run into problems with common
HTTP-tools, using both Postman and cURL to try to get Tomcat to accept the
input.
In both cases, Spring raises an exception as the request-parsing identifies NO
parts in the multipart request.
## Suspected Bug
To me, the culprit appears to be the parsing of request-part names in
`org.apache.tomcat.util.http.fileupload.FileUploadBase#getFieldName`, which
requires each request parts Content-Disposition to start with "form-data" and
`org.apache.tomcat.util.http.fileupload.impl.FileItemIteratorImpl`, which
discards any parts it cannot get a name for.
## Expected Behaviour
My understanding from these specs
- https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
- https://www.ietf.org/rfc/rfc1867.txt
is, that this requirement on the Content-Disposition needs only be the case for
requests with Content-Type: multipart/form-data. Therefore, I believe
multipart-requests should also be accpeted with Content-Type: multipart/mixed
and arbitrary Content-Disposition.
Please confirm whether you agree, I'm not at all deeply versed in HTTP.
## Workaround
When generating requests in both Postman and cURL (with the --form parameter
for each part, e.g.
--form partname=<partcontent.json) generate the Content-Disposition to start
with "attachment" instead, when using multipart/mixed.
This (again, to me) appears to be acceptable per the spec, but not compatible
with the Tomcat implementation.
In curl, this can be worked around by setting the Content-Disposition of each
part manually:
--form 'file=<file.pdf;type=application/pdf;headers="Content-Disposition:
form-data; name=datei; filename=file.pdf"'
Once the parts contain the right Content-Disposition, Tomcat correctly parses
each part.
## Aside
I'm not completely certain if FileUploadBase _means_ to support multipart/mixed
at all, even though I would wish it to do.
The class comment I can see states (abridged for legibility):
> This class handles multiple files per single HTML widget, sent using
> multipart/mixed encoding type, as specified by RFC 1867.
> Use parseRequest(RequestContext) to acquire a list of
> org.apache.tomcat.util.http.fileupload.FileItem s associated with a given
HTML
> widget.
The usage in Spring obviously does not concern HTML widgets only, as this code
path seems to be used for any multipart-request.
The focus on HTML widgets would, to me, explain only the form-data spec is
followed.
However, the comment also mentions the multipart/mixed type. Is this mention
only in reference
to using multiple files in the same request-part by designating a single part
as multipart/mixed as per the spec?
======================================================================================
Ideally, I would prefer this to be resolved by more leniently accepting
different Content-Dispositions in request-parts.
If this is not acceptable, I'm unsure if it would be wise for my code to rely
on the _incidental_ support for other multipart requests, as long as the
Content-Disposition of the request parts starts with form-data.
Please do tell if I missed something here.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
