Menu
Community /Pin to ProfileBookmark
@PeterPan_321Jun 06.2019 — #I don't use AJAX nor Springboot, ( straight javascript and PHP for me). But I can tell you my usual PHP code for downloading a file looks like this...
Now if change the content type to application/octet-stream, (which looks similar to your call), even on a desktop its unpredictable. If its an MP3 or a PDF for example, firefox will try to render or play it, where Chrome will usually just download it. The 'x-file-to-save' instead will either cause download, or an alert box asking whether the user wants to "play/view" the file or save it.
But, I'll also say that I generally block calls to download a file on mobile devices, because the result is hard to control and is often useless. Remember that most (or at least ale ones I know) phone browsers don't have any "file system" to download to. So unless its a file type the browser can directly deal with (many can display PDFs), the end result becomes difficult to predict.
On the client side web page, I'll usually call a PHP file containing my script with an XMLHttprequest, formating the script string with all the parameters I need to pass (in this case a file). Don't know if any of this helps, as I'm not using your platforms
PDF download Issue on mobile UC browser
Hello,
I am using springboot, while downloading pdf file by ajax call in UC mobile browser it is gives protocol not supported Error.
Can you guys let me known what is cause?
Thanks,
Sign in
to post a comment11 Comments(s) ↴
0
@PeterPan_321Jun 06.2019 — #I don't use AJAX nor Springboot, ( straight javascript and PHP for me). But I can tell you my usual PHP code for downloading a file looks like this...``<i>
</i>function downloadFile($path) {
$path_parts = pathinfo($path);
$ext = strtolower($path_parts["extension"]); // don't need this.
$fsize =fileExists($path);
if ($fsize == 0) return 0;
header("Cache-Control: public");
header("Content-Description: File Transfer");
header("Content-Disposition: filename="" . $path_parts["basename"].""");
header("Content-Type: application/x-file-to-save");
header("Content-Transfer-Encoding: binary");
if($fsize) header("Content-length: $fsize");
$bytesRead = readfile($path);
return $bytesRead;
} <i>
</i>``Now if change the content type to application/octet-stream, (which looks similar to your call), even on a desktop its unpredictable. If its an MP3 or a PDF for example, firefox will try to render or play it, where Chrome will usually just download it. The 'x-file-to-save' instead will either cause download, or an alert box asking whether the user wants to "play/view" the file or save it.
But, I'll also say that I generally block calls to download a file on mobile devices, because the result is hard to control and is often useless. Remember that most (or at least ale ones I know) phone browsers don't have any "file system" to download to. So unless its a file type the browser can directly deal with (many can display PDFs), the end result becomes difficult to predict.
On the client side web page, I'll usually call a PHP file containing my script with an XMLHttprequest, formating the script string with all the parameters I need to pass (in this case a file). Don't know if any of this helps, as I'm not using your platforms