We Keep Coding

Is it possible to change HTTP-header of a pdf document, you want to embed in a <embed> or <iframe>?

Refering to my other question: Why does pdf document download instead of showing in a embed/iframe?
When i embed a pdf document like the below examples, it downloads the documents instead of showing it embedded in the website.
<embed id="showPdfDocument" src="http://example.com:8080/client/attachment/filename.pdf" type="application/pdf" width="400" height="400">
or
<iframe id="showPdfDocument" src="http://example.com:8080/client/attachment/filename.pdf" style="width:400px;height:400px;"></iframe>
My assumptions:
I guess i have to change the HTTP-Header of the pdf document?
I also guess that the problem is with the field "Content-Disposition: attachment", as shown in the screenshot below
My question:
How can i change the HTTP-Header of the pdf document, using html/javascript only? (Greasemonkey for example)
Screenshot of the HTTP-Header of the pdf document:
("Chrome Dev-Tools(F12)" -> Network Tab, select the pdf document and check the response headers)

The content-disposition header triggers the save dialog. If you want to avoid it without server-side changes, try loading it via XHR and encode it as "data:" link.

How to prevent Mobile Safari from inserting a PDF's base64 encoded URL into an email when sharing?

I have a javascript web app that generates PDFs client side in a user's browser (using pdfmake).
In mobile Safari a user can open this PDF and view it natively, but when they go to share it by email the message inserts the entire base64 encoded URL for the PDF into the email and it quickly becomes unwieldy.
What workaround do I need to do to stop it from doing that? Is there not some way to specify a default message (perhaps in some meta data) when a user goes to share a document by email?
Currently the user experience is unacceptable because a user has to delete the entire base64 URL before they send their message, which is several pages long.
I would rather not have to send the PDF to a server first to get a smaller URL.

Well, you could circumvent the browsers share by email, by providing your own, leveraging mailto: somewhere the user can see it...
Another idea, untested, is you could wrap the PDF in an iframe, then when the page is forwarded, the host page, not the PDF would be shared, this may require the use of a PDF viewer script, such as google's, something like:
<iframe src="https://docs.google.com/viewerng/viewer?url={{ URL to your PDF goes here }}&embedded=true" frameborder="0" height="100%" width="100%">
</iframe>

When user go-to share by email option, then decode the Base64 as follows
let decodedData = NSData(base64EncodedString: base64String!, options: NSDataBase64DecodingOptions(rawValue: 0))
let decodedString = NSString(data: decodedData, encoding: NSUTF8StringEncoding)
print(decodedString)
Now use decodedString as message body in MFMailComposeViewController
mailComposerVC.setMessageBody(decodedString, isHTML: false)

How to change browser title while providing file download

I am trying to set the title of the browser dynamically as the PDF document title. But the title currently gets displayed as the URL of the document.
I'm providing the PDF download as below:
response.setDateHeader("Expires", 0L);
response.setHeader("Content-disposition", "inline;filename=" + title + ".pdf");
response.setContentType("application/pdf");
response.setContentLength(bArray.length);
response.getOutputStream().write(bArray);
How can I set its title in browser?

You can't change the title of the html page which shows your response pdf file. The browser will set the title automatically from the meta data of the pdf which you are returning from your server.
So the simple step to change the title of the pdf preview browser is to set the metadata for your pdf file correctly.
You can find the metadata of your pdf from "File-> properties -> Title"
Browser is showing the title from this information only.

Detecting iframe load when downloading a file through the iframe

I'm using AngularJS and setting ngSrc on an iframe, which I use to download a zipped archive to get around not being able to download files using AJAX. I'm using a directive for detecting the iframe load that I found here, which works great when you load a URL like "about:blank", but it doesn't have a load when I hit it with a RESTful call to download the file, even though it downloads the generated file.
// Markup of iframe using ngSrc and custom directive
<iframe ng-src="{{url}}" style="display:none;" iframe-onload="myCallback" />
// Controller setting iFrame, what I'd like to trigger the load
$scope.downloadArchive = function( id ) { // no load event? but downloads zip archive
var url = '/data/archive/instance/' + id;
$scope.url = $sce.trustAsResourceUrl( url );
}
// Controller setting iFrame, what does trigger the load
$scope.downloadArchive = function( id ) { // load event triggered
$scope.url = $sce.trustAsResourceUrl('about:blank');
}
Is is possible to detect an event when downloading a zipped archive through the iframe?

Is it that you can't download the file via AJAX due to browser restrictions? Like cross domain issues? You can find out by examining the error in Chrome Console.
If that is the case, you won't be able to view the contents of the file in an iframe either due to modern browser restrictions. Think of what can happen if developers are allowed to access the contents of any iframe. I could make a website with your bank's website in an iframe. Once you log in, I'd be able to listen to a form submit event from the iframe and then get your login credentials.
Hence, what could be happening is that your iframe is loading the file, trying to display the file within it, but intentionally hindering you from viewing its contents for security.
I'd recommend downloading the file via a proxy server you own or through a cloud service, and then serving the file from your own server. This circumvents cross domain issues since you can now ping your own server.

I ended up not trying to reset the URL each time and just appended the current time as a second parameter, which gets ignored by the server. Now it appears like iframe is reloading a new URL.
var url = '/data/archive/instance/' + id + '/' + Date.now();

How can I print a PDF fetched via an ajax request?

I'm having a form that once submitted, the PHP generates a PDF file and sends it to the client. Everything works fine so far. What I'm having trouble with is that I need to trigger window.print() on the window containing the received pdf. Is there a way to make the printing wizard appear for the received pdf file?
Here is the code I have
//The #options is a form that once submitted is sends the requested PDF to the browser
$('#options').on('submit', function(e){
if($(this).find('[name="action"]').val() == 'print')
{
var url = $(this).attr('action') || document.URL;
e.preventDefault();
$.post(url, $(this).serializeArray(),function(pdf){
// Open the printing wizard for the requested document
});
}
else
{
// The PDF is displayed normally
return true;
}
});
I'm not even sure if what I want to do is possible. Is is possible for example to open the PDF in a new tab and call window.print() there?

One easy approach for this is to put the PDF file in a new iFrame.
Then you can print the complete content inside the iframe using window.print(); function.
<html>
<head>
<title>Print Test Page</title>
<script>
function printPDF() {
window.frames["print_frame"].window.focus();
window.frames["print_frame"].window.print();
}
</script>
</head>
<body>
Some content here
<iframe name=print_frame width=0 height=0 frameborder=0 src=about:blank>
Your PDF is loaded here
</iframe>
Some more content here
</body>
</html>
Now call window.print(); function when you want to print your pdf.

To open PDF in new window, you need to essentially generate an GET request (so that window can be open via URL) - one of the simple way is to code your server side code to accept the input parameters via query string. Better way is to use POST request (as you are currently doing) to generate the PDF at the server side and cache it in temp location, then return some token/ticket (e.g. it can be as simple as temp file name) to the browser. This token would be used in GET request to get the PDF file - GET request would go to server that would simply read the file off temp location and return it back as inline ((i.e. header content-disposition: inline;). Then you may try window.print() to print it. Similar ways can be used with iframe (with contentWindow.print()).
However, you may find that these solutions may not work - for example, there is no PDF plugin to display the PDF inline (or user has chosen always open file externally). Or it may not work across browser. So yet another (and IMO better) way is to embed java-script within PDF it self to instruct for print as soon as the file is opened.
For example, see this PHP code example that would embed java-script in PDF generation for auto printing - the example is using FPDF for PDF generation.