How to make Spring (or Jetty) accept/parse Multipart uploads where the body part(s) miss(es) the filename attribute in the Content-Disposition?
Otherwise than the missing filename attribute, the Multipart message is OK and it also used to work with an older version of Jetty/Spring.
What do I need to set to make Jetty/Spring a little more error tolerant again?
P.S.
Here I found a similar yet different problem (name attribute missing). Yet, while the name seems like a vital attribute to identify body parts, you do not necessarily need the original client-side filename: Spring POST multipart/form-data Request empty body, getParts always empty
As already mentioned in the comment:
Spring (4.3.8.RELEASE) unconditionally skips multipart files without a filename, i.e. there is no setting to make it more error-tolerant. Thus, the only solution was to override Spring's StandardMultipartHttpServletRequest class and modify the method in question: parseRequest.
The added lines of code:
if (filename == null && "file".equalsIgnoreCase(part.getName()) && MediaType.APPLICATION_OCTET_STREAM.equalsIgnoreCase(part.getContentType())) {
filename = DEFAULT_FILENAME;
}
And yes, the name of the multipart body part doesn't necessarily have to be "file" but this is the name the client application my code has to work with is using when uploading a file.
Related
I have this code:
#PostMapping("foobar")
public ResponseEntity<SaveLogsResult> foobar(#RequestPart("file") MultipartFile log, #RequestPart("env") MultipartFile json){
return ResponseEntity.ok(fooService.saveFooBar(log, json, UUID.randomUUID().toString()));
}
Two applications send formally correct data to this endpoint, one fails miserably and receives an http status 400.
I set logging.level.org.springframework.web=DEBUG and can see (among other lines) this:
Required request part 'env' is not present
Resolved [org.springframework.web.multipart.support.MissingServletRequestPartException: Required request part 'env' is not present]
Completed 400 BAD_REQUEST
To further diagnose this I compared a working (left) and a non-working (right) request. The only different is the mising filename:
As far as I understand the RFC for Content-Disposition leaving out the filename is perfectly valid:
Is followed by a string containing the original name of the file
transmitted. The filename is always optional and must not be used
blindly by the application: path information should be stripped, and
conversion to the server file system rules should be done. This
parameter provides mostly indicative information. When used in
combination with Content-Disposition: attachment, it is used as the
default filename for an eventual "Save As" dialog presented to the
user.
Is this an error inside Spring ? I use Spring Boot 2.6.2
Unfortunately I can't change the non-working component for a quick test because it is a bought component that doesn't receive bugfixes very often.
I think that my problem is different from that described here because the failure only happens in a specific scenario.
It looks like you have to provide the filename. see this issue
This [The situation in which filename is not present] can lead to inconsistencies, e.g. you would get it with
MultipartFile but not with collection or array of MultipartFile, and
one can make the opposite argument that it should be rejected.
Why does it matter to have it injected as MultipartFile if it doesn't
even have a filename? You could also inject it as InputStream or any
other type supported by a registered HttpMessageConverter.
I have two model files in java spring boot where in one i have declared the variables for database and another one to include file in Request body itself.
I have a controller which takes the request body this. How can i send the following request in postman. Is there better way of doing including a file and my other model class rather than just passing it as request param.
public String saveReferenceData(#RequestBody TestClass testClass){
// custom logic written
return "done";
You should use multipart request for handling files and text data. Multipart request is similar to any other payload but defined boundaries for server to handle and parse.
To Upload multipart file In postman:
Switch to body tab
select form-data
add keys
Alternative solution
Dothttp is similar tool with great control over these.
For Multipart upload
POST https://req.dothttp.dev
// selects as multipart
multipart(
'name'< 'john',
'photo'< 'C:\Users\john\documents\photo.jpg',
// and many more
)
My task is to implement a webservice that:
consumes an XML file on a POST endpoint
in happy flow, it returns a DTO as JSON + HTTP 2xx
the incoming XML file is validated against a XSD; if the validation fails, a JSON with a list of all validation errors is returned (including the line, column, error) with HTTP Bad request
the application exposes two endpoints, only one of them should be validated
I have started the implementation with Spring Boot + web, using regular #PostMapping which has "consumes" and "produces" set to application/xml and application/json, respectively. The usual flow works perfectly fine. Now, I stumbled upon the issue of validating the incoming payload. What I figured out:
1) I have to validate the payload before it is converted (marshalled) to an object.
2) Once validated, I have to either:
allow further processing
stop any further processing, write the error object to the response and set the status code to 400 Bad request
My approaches were:
1) using a RequestBodyAdvice, more specifically the beforeBodyRead method implementation. I had the following issue here: I don't know how to write anything to the output in case the validation fails.
2) using a Filter (I've extended OncePerRequestFilter) - fortunately, I can read the request (request.getInputStream()) and write to the response (response.getOutputStream()).
However, how can I do the selective filtering (as mentioned, I only want to validate one single endpoint)?
Are there any other alternatives for placing the incoming request XSD validation? Is spring-web the appropriate choice here? Would you recommend some other library / framework?
To validate xml against xsd schema, my preference is XML Beans. It is very easy to use. Other options are JABX, Castor. Take a look at Java to XML conversions?.
You will need to jar using xsd schmema and will need to put it in the classpath of your application so that it's classes are available for you for validation. Please take a look at this blog.
You can use validation API as mentioned here.
I would prefer to write validation code in the aspect so that it can be reused with other APIs.
If validation fails, throw valid exception from the aspect itself.
If validation is passed, process your input string that you receive.
Please let us know if you need any more information.
I'm attempting to simulate a login call with JMeter 2.11 to a service that uses a binary format. I've created an Http Request with the appropriate settings, except for the body data. I need to POST raw binary data.
According to the docs here, I should be able to set the file path for exactly one file, with no parameter name, and no other content in the Body Data, and have it place the data in the request body.
If it is a POST or PUT or PATCH request and there is a single file whose 'Parameter name' attribute (below) is omitted, then the file is sent as the entire body of the request, i.e. no wrappers are added. This allows arbitrary bodies to be sent. This functionality is present for POST requests after version 2.2, and also for PUT requests after version 2.3.
However, when I run the test, the POST Data is empty.
I have tried the extra set of plugins for JMeter as well, but alas, I'm stuck. The loaded file has 145 bytes of data, and the request shows that the content-length is 0. What am I missing?
The Http Request
The result
Update 1
To clarify, I am NOT attempting to send a file, I'm attempting to send a binary encoded message as raw POST data.
Switch back to Parameters tab not Post body.
See:
http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Request
Yoy could try recoring to see how the resuest look like.
This is my solution,maybe not best, but it works fine:
1st step :
You should write your binary data to a file (assume it's name is
FILENAME);
2nd step :
For your http request sampler,Yout should put ${FILENAME} under file
path in the "Send Files with the request" section (while leaving its
paramter name empty and specifying an encoding (for binary, it is
application/binary)).
Hope it helps.
Refer to this article
I'm using Spring 3 ability to upload a file. I would like to know the best way to validate that a file is of a certain type, specifically a csv file. I'm rather sure that checking the extension is useless and currently I am checking the content type of the file that is uploaded. I just ensure that it is of type "text/csv". And just to clarify this is a file uploaded by the client meaning I have no control of its origins.
I'm curious how Spring/the browser determines what the content type is? Is this the best/safest way to determine what kind of file has been uploaded? Can I ever be 100% certain?
UPDATE: Again I'm not wondering how to determine what the content type is of a file but how the content type gets determined. How does spring/the browser know that the content type is a "text/csv" based on the file uploaded?
You can use
org.springframework.web.multipart.commons.CommonsMultipartFile object.
it hasgetContentType(); method.
Look at the following example http://www.ioncannon.net/programming/975/spring-3-file-upload-example/
you can just add the simple test on CommonsMultipartFile object and redirect to error page if it the content type is incorrect.
So you can also count the number of commas in the file per line.There should normally be the same amount of commas on each line of the file for it to be a valid CSV file.
Why you don't just take the file name in you validator and split it, the file type is fileName.split("\.")[filename.length()-1] string
Ok, in this case i suggest you to use the Csvreader java library. You just have to check your csvreader object and that's all.
As far as I'm aware the getContentType(String) method gets its value from whatever the user agent tells it - so you're right to be wary as this can easily be spoofed.
For binary files you could check the magic number or use a library, such as mime-util or jMimeMagic. There's also Files.probeContentType(String) since Java 7 but it only works with files on disk and bugs have been reported on some OSes.