I created a file and named it as test.txt. The file contains the following:
<!DOCTYPE html>
<body>
Testing ...
</body>
When I point a browser to it, the content of the file is not rendered. If I renamed the file to test.htm, it gets displayed correctly, i.e., w/o the markup symbols. Would someone please explain the significance of the suffix, or point me some documentation regarding that? Thank you.
On a file system, the file extension is to determine what type of data is stored in a file.
In an HTTP URI, it is meaningless … however if you are mapping URLs onto a file system (the usual method of serving static content) then the web server will use the file extension to determine the Content-Type HTTP response header which is used by the browser to determine the type of data.
Related
I am building a web app and I would like to show PDF files to my users. My files are mainly stored as byte arrays in the database as they are generated in the backend. I am using the embed element and have found three ways to display a PDF:
Local file path in src attribute: Works, but I need to generate a file from the database byte array, which is not desirable as I have to manage routines to delete them once they are not needed anymore.
Online file path in src attribute: Not possible since my files may not be hosted anywhere but on the server. Also has the same issues as the previous method anyway.
Data as base64 string in src attribute: Current method, but I ran into a problem for larger files (>2MB). Edge and Chrome will not display a PDF when I covert a PDF of this size to a base64 string (no error but the docs reveal that there is a limit for the data in the src attribute). It works on Firefox but I cannot have my users be restricted to Firefox.
Is there any other way to transmit valid PDF data from a byte array out of the database without generating a file locally?
You have made the common mistake of thinking of URLs and file paths as the same thing; but a URL is just a string that's sent to the server, and some content is sent back. Just as you wouldn't save an HTML file to disk for every dynamic page on the site, you don't have to write to the file system to display a dynamic PDF.
So the solution to this is to have a script on your server that takes the identifier of a PDF in your system, maybe does some access checking, and outputs it to the browser.
For example, if you were using PHP, you might write the HTML with <embed src="/loadpdf.php?id=42"> and then in loadpdf.php would write something like this:
$pdfContent = load_pdf_from_database((int)$_GET['id']);
header('Content-Type: application/pdf');
echo $pdfContent;
Loading /loadpdf.php?id=42 directly in the browser would then render the PDF just the same as if it was a "real" file, and embedding it should work the same way too.
I'm new to Jmeter and am trying to use variables from a CSV file in the path of my HTTP GET request.
I've looked through various tutorials and answers to this question, but I still can't figure out what I'm doing wrong. The file just has one header (ID). It works if I enter the ID in the path, but as soon as I try read it from the CSV file, it fails:
Your configuration looks good, double check jmeter.log file for any suspicious entries.
Other recommendations:
Given you have only a single column it might be easier to use __StringFromFile() function directly in the HTTP Request sampler body like:
/api/Users/${__StringFromFile(c:\Automation\Test.csv,,,)}
I believe Content-Type and Authorization should go in HTTP Header Manager, not in the request parameters
See Testing SOAP/REST Web Services Using JMeter article for more details.
The problem wasn't with the reading of the variable. I thought that the first line of the file would be treated as a header, but it reads the first line of the file as a variable, so my file looked like:
ID
001
It read "ID", when I wanted it read "001.
I have a file hosted on AWS Linux AMI. The link is http://54.179.188.146/a/a.docx I can visit the link and download the file.
I am trying to use Microsoft Online Doc Viewer to view the Word File online at this link https://view.officeapps.live.com/op/view.aspx?src=http://54.179.188.146/a/a.docx but it returns a page stating "An error occurred We're sorry, but for some reason we can't open this for you."
I had chmod the file to 775 but it still cannot view.
I had uploaded to another server and it is working. May I know what is wrong? Is it a server configuartion issue? Please advise.
Thanks.
This is Old but giving some more pointers to the new visitors , i am posting the consolidated answer for the root cause of the "We’re sorry, but for some reason we can’t open this for you" error in https://view.officeapps.live.com/op/view.aspx?src=
If you see the error, "We’re sorry, but for some reason we can’t open this for you," it means the document could not be found or could not be displayed. Likely reasons include:
There’s no document to be found at the URL you provided. Make sure
you provide the correct URL.
The document is too large. Word and PowerPoint documents must be less
than 10 megabytes; Excel must be less than five megabytes.
The document was not saved in a format that is supported for opening
in a web browser. Try saving your document in one of the following
formats:
Word: docx, docm, dotm, dotx
Excel: xlsx, xlsb, xls, xlsm
PowerPoint: pptx, ppsx, ppt, pps, pptm, potm, ppam, potx, ppsm
You need to sign in or provide a password to open the document. Make
the document publically available to view.
The document’s file name contains invalid characters. Try encoding
the file name when you type the document’s URL, or rename the file to
use only letters and numbers. For example, to encode a URL that
includes an ampersand (i.e. &), you would type %26 for the ampersand
character. For more information about URL encoding, also known as
percent encoding.
more info can be found here
The value after "src=" should be URL-encoded. See details on MS Page
You should checked all reasons from here
There’s no document to be found at the URL you provided. Make sure you provide the correct URL.
Try to open file from browser.
Make sure you don't try to send on preview service path of the file from your local host. To which, obviously, there is no access from the Internet.
Path to file must be http:// or https://
If path to your file start with https:// make sure your site have necessary secure certificate.
Domain name matters.
Will not be open in preview service
http://185.231.70.200/vacuumcleanerprocedure.doc
Will be open in preview service
http://domainname.com/vacuumcleanerprocedure.doc
The document is too large. Word and PowerPoint documents must be less than 10 megabytes; Excel must be less than five megabytes.
Try different files with different Microsoft file types.
The document was not saved in a format that is supported for opening in a web browser. Try saving your document in one of the following
formats: Word: docx, dotx Excel: xlsx, xlsb, xls, xlsm PowerPoint:
pptx, ppsx, ppt, pps, potx, ppsm
Try different files with different Microsoft file types.
You need to sign in or provide a password to open the document. Make the document publicly available to view.
File permission and folders mode should be 775.
Check if in .htaccess file of your apache server there are allow access to ms-office files.
Check if your file available from internet. Try to open file from browser. If you see “You don't have permission to access filename on this server” see answer here
The document’s file name contains invalid characters. Try encoding the file name when you type the document’s URL, or rename the file to
use only letters and numbers. For example, to encode a URL that
includes an ampersand (&), you would type %26 for the ampersand
character. For more information about URL encoding, also known as
percent encoding, see Percent-encoding on Wikipedia.
The value after "src=" should be URL-encoded. When you place the link on the preview service, it already encodes it for preview. Additionally, I may encode the link here, but the result will be the same.
I'm trying to write an extension that corrects 'incorrect' content types. An example situation is a user might click on a link to a PDF file that has the HTTP Content-Type set to application/octet-stream. In this case, I want to be able to detect that the real content type is application/pdf.
A simple but not-so-robust way to do this would be to define my own mappings from file extensions to content types. However, it would be good if I could re-use existing work to do this.
I noticed that Chrome is able to determine how to display files obtained via the ftp and file protocols, which I don't believe provide content type information. How does Chrome do this? Does it inspect the file contents? Does it check the file extensions? Most importantly, can I programmatically hook into this content type detection functionality for my extension?
I Wonder whether I can use pdf Source[as hyperlink] as a file path in system related to script's running directory.
part of code is.
pdf
I am generating this HTML using CGI Scripting in C. and my pdfs are located in ../pdfs/sample.pdf related to my running directory of script. And by pdf source means I want to show the pdf sample.pdf upon clicking pdf as in above sample code.
A browser does not care or know how a resource is generated. You can generate it with C via CGI, you can have the server just hand over a static file. There is no difference as far as the browser is concerned, it made an HTTP request and received an HTTP response.
The rules for resolving a relative URI in an HTML document are the same. The browser compares it to the base URI (which is either specified in <base> or is the URI of the document containing the link).
If that resolves to a URI that the server will serve a PDF up for, then it will work.
Since URIs don't always map directly onto file systems, it isn't possible to say if this will work in your situation (as your question only talks about file systems). If this was on one of the servers that I have CGI programmes executing on then it wouldn't work — since I keep them in a cgi-bin that isn't a subdirectory of the webroot, so the pdfs wouldn't be accessible over HTTP at all. Your server may be configured differently.