Link to HTML doc can only offer download, not display Options

[Leezinho]

I want document A to link to document B, and for document B to activate some JavaScript segments, online.
I have composed document B in HTML and then used an online converter to convert it to a PDF,
but the resulting PDF seems unable to operate JavaScript.
But if I keep B as an HTML document, when document A tries to link to it, my browser offers only to download document B.
I don't want to make the user download anything. I just want them to be able to operate the JS files online.

[pandy]

I don't understand. Why would a browser offer to download a HTML document? What else have you done?

[Leezinho]

I don't understand. Why would a browser offer to download a HTML document? What else have you done?

That's my question exactly: Why would a browser only offer to _download_ a page, instead of going directly to it?

[Christian J]

Sounds like the browser doesn't recognize the page as an HTML document. This might be due to an incorrect Content-type type value being sent in the page's HTTP header (it should be "text/html").

If you post the URL here we can have a look, or you might check it yourself in the browsers' Developer tools (choose Network, reload, and click on the row for the HTML file; other browsers work in similar ways). There are also online sites showing the HTTP headers for URLs you enter.

[pandy]

Sounds like the browser doesn't recognize the page as an HTML document. This might be due to an incorrect Content-type type value being sent in the page's HTTP header (it should be "text/html").

Yeah, but I don't see how that is likely to happen to a single page. If the page has accidentally got the wrong (mumbo jumbo) extension it would be served as txt.

Yeah, can you link to the page so we can see for ourselves?

[Leezinho]

Here are the two lines from my HTML mentioning "Content-Type":

<meta http-equiv="CONTENT-TYPE">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

Am I missing some quotation marks?

[pandy]

No, but that is overridden by real HTTP headers sent from the server. The reason W3C recommends (or at least recommended) using META for charset is in case the document is saved to the user's hard drive and viewed locally. Don't remember what they say about content type.

[Christian J]

Here are the two lines from my HTML mentioning "Content-Type":

No, the HTTP header (where the Content-type in question can be found) is not part of the actual HTML file. It is sent by the server along with the file, and is normally not seen by the user unless you look for it in the ways I mentioned before.

For example, when a browser requests a file with an .html extension, a properly configured server would send a "text/html" Content-type in the HTML file's HTTP header. A file with a .pdf extension should be sent with "application/pdf".

[pandy]

If you post the URL here we can have a look, or you might check it yourself in the browsers' Developer tools (choose Network, reload, and click on the row for the HTML file; other browsers work in similar ways).

Is that the column named "Type"? I always thought that was just the extension of the file, but maybe it's an abbreviated content type? For a HTML document it says html, for an image it says gif...

[Christian J]

No, the response headers are in a section of their own. Here's what it looks like in Firefox:

[pandy]

Hmm. I don't have that right pane at all. How do I make it visible?

[pandy]

[Christian J]

Click on the file and the menu will show up.

Unless you only show HTML files, there will be a list of all other files used by the page as well, but we don't need to view them in this case.

[pandy]

Duh. Thank you!

I've used a plugin for IE like forever. Never bothered to find a replacement when I lost it with the computer before this. But this does the job, I see.

[Leezinho]

Okay, here's my URL:
<langnhist.weebly.com>
Click on the picture of Doris Day and see if you get something other than the offer to download (FireFox) or an automatic download (Chrome).

[Christian J]

Seems all the link URLs use .pdf extensions. PDF files can either be downloaded or viewed online, depending on browser settings and capabilities.

In addition, the Doris day URL https://langnhist.weebly.com/files/theme/quesera2.pdf returns a "File not found" message.

[Leezinho]

In addition, the Doris day URL https://langnhist.weebly.com/files/theme/quesera2.pdf returns a "File not found" message.
[/quote]
Sorry. Now I've changed the link from PDF to HTML. Now my browser(s) insist on downloading the file.
Try Doris Day again, and let me know the result.

[Christian J]

https://langnhist.weebly.com/files/theme/quesera2.html seems to be a normal HTML document, but it's incorrectly served as "text/plain" by the server.

This is even more odd considering https://langnhist.weebly.com/index.html is served as "text/html" like it should. The only difference I can see is that Doris Day is located in the sub directory "/files/themes/". Could you have changed something in any of those two directories, like adding a .htaccess file?

[Leezinho]

I don't know what a .htaccess file is.

For experimental purposes, I'm keeping the link from Doris Day to an HTML document, not PDF. I've added Safari to my list of browsers tried. Results:
• Firefox: Offers to download, only. (Or to "open with" various inappropriate readers.)
• Chrome: Downloads automatically, without asking.
• Safari: Goes directly and correctly to display the HTML document.
Do you get different results from these browsers when you try the Doris Day link on your hardware?

PDF files can either be downloaded or viewed online, depending on browser settings and capabilities.

I've looked at the Settings for FireFox and Chrome, and I don't see any that have to do with handling a link to an HTML document.

Weebly seems to require "files/theme/", I'm not sure why.

[Christian J]

I don't know what a .htaccess file is.

It's a file that can be used to change server configurations in folders.

I've added Safari to my list of browsers tried.

It's not a browser issue really, it's the server that sends incorrect information. Browsers are supposed to handle files on the web based on the files' associated Content type headers, not the file extensions. So if a file has an .html extension but is served as "text/plain" (like in your case), browsers should consider it a text file (just like we're seeing here). Seems Safari disobeys the spec (IE has been known to do the same).

PDF files can either be downloaded or viewed online, depending on browser settings and capabilities.

I've looked at the Settings for FireFox and Chrome, and I don't see any that have to do with handling a link to an HTML document.

That only applies for links to real PDF files. I think the default for Firefox currently is to open PDF files in the browser.

Weebly seems to require "files/theme/", I'm not sure why.

Sounds like a folder for some kind of themes. But that makes me wonder --why did you put quesera2.html there in the first place? Perhaps you're not supposed to have HTML files in that folder. Try moving it to the web root instead (where the index.html file is)!