I have updated my WildFly server from 10.1 to 18.0.0.
Now I'm facing wired issue while download PDF as well as XLSX or any file larger than 15kb.
Say for example,
if I try to download XLSX file of size 100kb,
I find some headers (like - Content-Type, Content-Length, Content-Disposition, etc.) missing from response object although I set those explicitily from my application while writing file in response output stream. As a result the file is getting downloaded of uknown format.
But if I try to download XLSX file of size less than 16kb, the file is getting downloaded in correct format will all response headers present as I set.
I know it's too wired and parhaps this question seems silly or owakward but let me assure you that everything was good until we had older WildFly 10.1.
Can anyone give an idea what could be the reason?
Thanks
Jeet
Related
I want to compress a file to ".tgz" extension using apache camel 3.11.1.
As the gzip format is not supported, I tried GZipDeflater data format but it is not working (the file remains unchanged).
I found a solution, maybe it can help someone else.
The solution was to use gzipDeflater DataFormat, and explicitly provide the extension in the file endpoint when producing the result:
from("file:...../in?noop=true")
.marshal().gzipDeflater()
.to("....../out1?fileName=${file:name.noext}.tgz");
I'm wondering if anyone has ever encountered a situation where it was necessary that the mimetype file be put into the zip file first (and uncompressed) to make the ePub work. And I'm not talking about the ability to pass an ePub validation.
I've been trying to write a script to create ePubs and it's not working. I tried several variations of the 7zip flags and every time the validation complains about the mimetype file.
I got fed up and just opened one of the files in Digital Editions and it worked fine. Then opened it in Calibre, dropped it into Chrome (ePub Reader), in iBooks, and even made a Kindle file. Everything worked as expected without throwing up an error.
Is there any situation where this matters...apart from the OCD part of me wanting an error-free file?
The answer appears to be "no"...
But here are a sampling of posts fighting with the Mimetype file error:
Make MIMETYPE file the first file in an EPUB ZIP file?
Creating an Epub file with a Zip library
creating *.epub with perl Archive::Zip -- epubchecker error
How to create ePub with System.IO.Compression.ZipArchive?
The mimetype file has an extra field of length n. The use of the extra field feature of the ZIP format is not permitted for the mimetype file
I want to load data into a greenplum database with gpload.py (Windows Server). But I only get a weird output:
|ERROR|A gload control file processing error occured. The gpload:input:source(1):file entry must be a YAML sequence
I tried to use gpload with linux and it worked fine. So my yaml file and my input data should be correct.
Does anyone know how to fix that problem?
You should post the yaml config file you are using to make sure there are no other problems. But I would guess since you said that it works on linux but not on windows that you have a line ending problem.
YAML files are line and whitespace sensitive. Try editing the file with a local editor on the Windows machine.
We have a PDF file download link on a web page with a C language CGI program actually passing on the file from our embedded device's web server. The web server is custom coded because of severe memory limitations.
The suggested filename by the C program is "Manual.pdf".
On Internet Explorer 8, when we click on the link the usual "Open/Save" box opens with the suggested filename displayed being "download.pdf" which is wrong. On Firefox, the suggested filename is "download.cgi" which is worse. However both browsers correctly indicate that the download is a PDF type.
Here are a few unrelated snippets of code to show the headers we are returning:
{ CONTENT_TYPE_PDF, "application/pdf\nContent-Disposition:attachment;" }
sprintf(tmpBuf, "Content-Type: %s\n", get_tbl_string((tbl_str_itm_t*)content_type, session->response.contenttype));
strcpy(tmpBuf, "filename=Manual.pdf\n");
strcat(tmpBuf, "Cache-Control: no-cache, no-store\n");
Can anyone tell what we are doing wrong?
Any help greatly appreciated.
Best regards,
Bert
The "filename" stuff is part of the content-disposition header.
Content-Disposition: attachment; filename=Manual.pdf header is good solution, however it doesn't work well if your filename has non-english characters. Another solution is to append "/Manual.pdf" path to your cgi script, i.e. use URLs like: http://server/path/my.cgi/Manual.pdf, and then your my.cgi program will be called with PATH_INFO=/Manual.pdf. For funky filenames, this works better than Content-Disposition header.
Update: If you are interested in browser support for Content-Disposition header, check http://greenbytes.de/tech/tc2231/.
Update: Another interesting article on the topic: Link
You might find some of the tips here useful:
http://blog.httpwatch.com/2010/03/24/four-tips-for-setting-up-http-file-downloads/
A webapp I've been developing allows users to upload and download a type of file which is meant to be treated as an opaque blob. My app serves it up with a file extension not commonly used for any other purpose, as well as specifying that its MIME Content-Type is application/octet-stream.
Internally, the file is a simple Zip archive containing a single compressed file. What I've found is that IE6 apparently inspects the content of the file, determines that it's a Zip archive, and "helpfully" saves it with an additional ".zip" extension. Unbelievable!
As I mentioned, this file is meant to be opaque, and we don't want users to be poking around inside the file--not because it's dangerous or contains sensitive information or anything, we just don't want to confuse them. I suggested prepending the Zip content with a magic number to prevent IE6 from recognizing it, but my manager says he'd prefer it if the file content could remain unchanged, so that knowledgeable people can rename the file and examine its contents as a zip archive, if necessary.
Is there any way to tell IE6 to keep its mitts off of the file? Or any alternative approach at all? (Alas, just not supporting IE6 at all is not an option.)
Incidentally, IE7 respects the file's name, but still identifies it as a Zip archive in the download dialog. That's better than IE6, but still less than ideal.
Short answer: Add correct MIME types to you web server so IE6 doesn't guess the file type.
Long Answer:
My work had a similar problem with Microsoft PowerPoint files.
.ppt vs .pps - Which are identical files with different extensions. We wanted the user to view a show (.pps) but IE6 kept changing it to .ppt. It changed the extention because the users machine had PowerPoint installed and understood that the file "looked" like a . ppt. Don't understand why not .pps.
The problem, besides IE6, was that our web server (IIS) was not aware of either MIME types for .pps or .ppt. So we had to add the correct MIME types so the server would not deliver them as "application/octet-stream". I understand that by using "application/octet-stream" IE6 will try to guess the MIME type.
So we added:
.pps = "application/vnd.ms-powerpoint"
.ppt = "application/vnd.ms-powerpoint"
Now it works fine with IE6.
I hope this helps solve your problem.
use this header flag: Content-Disposition: attachment; filename="yourfilename.extension"
This is a known problem, and the only solution is to edit the client computer's registry, which I'm sure doesn't help you a lot.