On the network where I have my web server there is a machine that has many zipped pdf files (zipped using java.util.zip) and I can access these files through HTTP. When a user wants to download a pdf file, I know how to unzip the file locally on the server first and then deliver the unzipped pdf to the user through a servlet. Is it possible to deliver the unzipped file to the user without unzipping it locally first?
Regards
In principle, if the client has said in his request that he accepts gzip-compressed data, you could send the PDF file in compressed form, and the client will decompress it. There is a gotcha, though: While the compression algorithm of zip files and the HTTP Content-Encoding: gzip is the same, the Zip file format has some more things around it (since it can contain multiple files, and a directory structure), so it would be necessary to strip these things off before. I'm not sure this would be much easier than decompressing in your servlet and then let your Servlet-engine take care of compressing again, but try it.
You can send the response to a request, encoded in a compressed format. If the client does the request with the header
Accept-Encoding: gzip, deflate
you can for instance serve him the content compressed using gzip (as long as you declare this through a header:)
Content-Encoding: gzip
Source: Wikipedia: HTTP Compression
Is it possible to deliver the unzipped file to the user without unzipping it locally first?
That depends a little bit on what exactly you mean with "locally", the general answer is "no". To deliver unzipped content, you have to unzip the zip first.
If you actually mean that the zip file is located at some non-local machine and that you currently need to save and zip it locally first before streaming unzipped content, then the answer would be "yes", it is possible to unzip and stream it without saving the file locally. Just pass/decorate the streams without using FileInputStream/FileOutputStream.
Related
I'm exporting an xls file from a Java backend but when the client receives it, it is recognised as an xlsx file despite it having the .xls extension in the name. I am using JasperXlsExporterBuilder to build the xls file.
When sending the file, I set the response type:response.type("application/vnd.ms-excel");
and the response headers: response.header("Content-Disposition", "attachment;filename=" + file.getName()); where file name is filename.xls
But still when the client receives it, the file is called filename.xls but it says You have chosen to open: filename.xls which is Excel 2007 spreadsheet (5kB) from: blob: this causes an issue as some excel versions can't handle the mismatch between the recognised type and the file extension.
Nothing you're doing is causing that; the computer that is downloading your file has a broken installation. For example, if the registry 'links' the .xls extension, you'd get that. You cannot detect this and cannot fix it (because you're a webserver; if you could detect or fix such things, you could also do malicious things, hence, you can't, and you never will be able to do such things from web servers).
One last ditch effort you can try which probably won't work (at which point you've exhausted all options available to you server-side) is to ensure that the URL itself ends in .xls. Make sure the user is following a link like https://www.user3274server.com/foo/bar/filename.xls.
I am working within Java, and downloading files from a HTTP Server. Now we are working with symlinks here, so we do not need to change the http link - it is always pointing to "last-uploaded.zip" which is linked to the last uploaded zip file, as an example "package43.zip".
Do I have the chance to get the original filename within java? So the link is pointing to "last-uploaded.zip" but if it is downloaded I want to rename it to "package$version.zip".
Regards,
Marco
No. The whole symlink concept doesn't transfer over HTTP, so when you make a HTTP GET for last-uploaded.zip you don't know if it's a file, a symlink or just an endpoint that returns bytes.
The simplest solution is probably opening the zip and searching for the version number from inside there somewhere.
While uploading a image/doc/xlsx file from my AngularJS client to my server-side java using JAX-RS(Jersey) i am getting the following exception,
org.jvnet.mimepull.MIMEParsingException: Reached EOF, but there is no closing MIME boundary.
What is this? Why I am getting this exception? How can I get rid of this?
Note: It works for the files with extension .txt, .html, .yml, .java, .properties
But not working for the for the file with extension .doc, .xlsx, .png, .PNG, .jpeg.. etc.
My Server side code:
#POST
#Path("/{name}")
#Consumes(MediaType.MULTIPART_FORM_DATA)
public String uploadedFiles(#Nonnull #PathParam("name") final String name,
#FormDataParam("file") final InputStream inputStream,
#FormDataParam("file") final FormDataContentDisposition content) {
}
I encountered the same issue. Based on my research, the problem has no relation with the file type. It has a little relation with the size of the uploaded file.
I'm not sure if the root cause is when the uploading file is very big, before the file is uploaded to the server completely, the client disconnects to the server (such as timeout). And I also verified the guess. My test steps is,
1. In client, upload a very big file.
2. Before the get the response from server, which means is uploading file;
close the test client
3. check the server side, you will see the issue.
So To fix it, my solution is add timeout time in client side.
OK, I'm only guessing, but I think I can see a pattern here.
The file types that are working are text based
The file types that are not working are binary
This suggests to me that maybe the problem is that there is some kind of issue with the way that non-text data is being handled by the upload process. Maybe it is being transcoded when it shouldn't be.
Anyway, I suggest that you use some tool like Wireshark to capture the TCP/IP traffic in an upload to see if the upload request body has valid MIME encapsulation.
I need to write REST resource that should receive a file and save it to the disk.
The files will be sent from jersey client.
For now, I see two options:
1. Using multipart
2. Just reading the inputstream as a string and saving it to a file.
What are the pros of using multipart? is it related to file size? or anything else?
Thanks
If you use Jersey server side, using multipart you gain
disk buffering (surely you don't want to retain huge files in memory)
automatic base64/binary stream conversion
If you choose the String option these benefits are unavailable.
See also my answer to the question JAX-RS Accept Images as input, there is a sample implementation of the multipart option
I need to send X number of files to my servlet from an applet, which is the best way to do this?
And I need to send before the files, a java object populated.
I need to do it all in a single connection.
I'll upload my applet 3 ~ 10mb to my servlet.
I currently use FileInput together with the OutputStream and BufferedOutputStream to send a file, causing the buffer size is 8K.
First time I'll try to zip all the files to upload a zip file to the servlet, but I know it's not a good solution.
In the Applet side, send it as a normal multipart/form-data request by either URLConnection or HttpClient. In the Servlet side, use either HttpServletRequest#getParts() or Commons FileUpload to extract the parts from the request. This way the applet and servlet are not tight coupled to each other, but just reuseable on different servers (e.g. PHP) and/or clients (e.g. a simple HTML page).
Whether or not to zip the individual files into a single zip file is a decision you'd need to make yourself based on coding and performance impact.