Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

External JS Files

Status
Not open for further replies.

DonP

IS-IT--Management
Jul 20, 2000
684
US
I have several external JavaScript files that are loaded into each of my documents. They work fine on my PC with PWS and on another Web server with NT IIS but they don't work on an Apache Linux server. Is there something I can ask the ISP to add to the configuration? They are willing to help in any way they can. In reading various Web sites, I understand that this needs to be done on some Web servers and I can't find anything else wrong, nor was it clear what needed to be done. Any help or suggestions is appreciated! Thanks!

Don
 
What kind of &quot;loading&quot; you use? If &quot;<script src=...&quot;, you need either add language=&quot;javascript&quot; or/and (and is better) type=&quot;text/javascript&quot;, or/and (and is better again) ask administrator add mapping of .js files to &quot;application/x-javascript&quot;. [sig]<p>Michael Dubner<br>Brainbench MVP/HTML+JavaScript<br>
[/sig]
 
Since my post, the ISP added the [tt]application/x-javascript[/tt] but it made no difference. The script is currently loaded as: [tt]<script language=&quot;JavaScript&quot; src=&quot;script.js&quot;></script>[/tt]

but I also tried it with the [tt]type=&quot;text/javascript&quot;[/tt]. Maybe now that [tt]application/x-javascript[/tt] has been added to the Apache server setup, that would be worth a try again. Thanks!

Don [sig][/sig]
 
Still having problems with loading external JS files on a Linux server with Apache via a service provider. The ISP has been really helpful and will do what it takes to make it work, but they are also stumped as to why it won't work. The exact same files work fine on NT with PWS and an NT Web server. The JS files themselves work fine if they are embedded int the HTML on either server, but that is not desirable for varions reasons (mainly because there are hundreds of documents invloved). Does anyone have more ideas?

Don [sig][/sig]
 
Why would you need server interaction in order to parse the .js file within your HTML file?

I have created several pages where i just write:

[tt]
<script language=&quot;JavaScript&quot; src=&quot;script.js&quot;></script>
[/tt]

And it works just fine locally.

Hope this helps.

-Vic [sig]<p>vic cherubini<br><a href=mailto:malice365@hotmail.com>malice365@hotmail.com</a><br><a href= software</a><br>====<br>
Knows: Perl, HTML, JavScript, C/C++, PHP, Flash, Director<br>
Wants to Know: Java, Cold Fusion, Tcl/TK<br>
====[/sig]
 
Hi Vic! I'm going only by what I see and by what people tell me since I am not an expert at this. I was told that a module might be missing from the Linux Apache Web server that is needed to properly handle external JavaScript files. I am already doing exactly what you suggested and it works fine but only on PWS and an NT Web server. On my NT system here with JavaScript debugging turned on, I get error after error popping up that each need to be closed before I can get to the online version of the site. It is a frames site so each document gives the error. On other setups without the debugging, IE reports &quot;Error on page&quot; in the status bar. Netscape of course, just ignores it and goes on as though nothing has happened. It could be something else entirely but I don't know what it might be. There were no errors before adding the external JavaScript, and the JavaScript code itself is exactly the same as on my PWS with no errors or issues at all - and the code is working just as it should, while it is not on the Linux Web server. The site is at:
Don [sig][/sig]
 
Well Im not sure if what Im seeing is correct or not, but it looks like your .js files are all just HTML files with a .js extension.

You cannot have regular HTML tags in your .js file if you are going to call it that way.


When my debugger opens secure.js this is what it shows me:

<HTML>
<HEAD>
<META HTTP-EQUIV=&quot;Content-Type&quot; CONTENT=&quot;text/html; charset=iso-8859-1&quot;>
<META NAME=&quot;DESCRIPTION&quot; CONTENT=&quot;Started around 1994, the OfficialAuthorized Yma Sumac Homepage has become the premier site for Yma Sumacfans. Biographies, Photo Albums and complete Discography are availablealong with Classified Ads, Chat Session, Forum, e-mailed Newsletter andthe exclusive source of the CD Yma Rocks.&quot;>
<META NAME=&quot;KEYWORDS&quot; CONTENT=&quot;Yma, Sumac, Ima, Imma, Sumack, Inca,Peruvian, Peru, Xtabay, Mambo, Rocks, Jivaro, Quechu, Biography, Photo&quot;>
<META NAME=&quot;ROBOTS&quot; CONTENT=&quot;NOINDEX, NOFOLLOW&quot;>
<META NAME=&quot;GENERATOR&quot; CONTENT=&quot;Mozilla/4.04 [en] (OS/2; I) [Netscape]&quot;>
<TITLE>Official Authorized Yma Sumac Homepage</TITLE>
<script language=&quot;JavaScript&quot; src=&quot;cgi-bin/nodeeplink.js&quot;></script>
<link REL=&quot;stylesheet&quot; HREF=&quot;html/style/style.css&quot; TYPE=&quot;text/css&quot;>
</HEAD>

<BODY TEXT=&quot;#000000&quot; LINK=&quot;#8C1919&quot; VLINK=&quot;#8C1919&quot; ALINK=&quot;#8C1919&quot; BACKGROUND=&quot;images/bg.gif&quot;>

<BASEFONT SIZE=2>

<CENTER>
<H3><B><FONT FACE=&quot;Helv&quot;><FONT SIZE=+2>Welcome to the<BR>
<I>Official Authorized Yma Sumac Homepage!</I></FONT></FONT></B></H3>
</CENTER>

<P><B><FONT FACE=&quot;Helv&quot;>Unfortunately, we are currently performing system
maintenance.&nbsp; Hopefully this work will not take long and the Homepage should
be up and running again in a very short time.&nbsp; Please try again later and
accept our apology for the inconvenience.</FONT></B>

<P><CENTER><B><FONT FACE=&quot;Helv&quot;>Your input is always welcome!<BR>
For comments, questions, suggestions, corrections, additions<BR>
or if you continue to receive this message for an extended time<BR>
or if you received it after accessing a particular file, please<BR>
<A HREF=&quot;mailto:pc@accesscom.com&quot;>e-mail us!</A></FONT></B></CENTER>

<P><CENTER><B><FONT FACE=&quot;Helv&quot;><FONT SIZE=-1>Copyright &copy;2000 by PC,
San Jos&eacute;, California, U.S.A.</FONT></FONT></B></CENTER>

</BODY>
</HTML>


Is this really what your secure.js file looks like, or am I getting the wrong thing?


Regards,
Gerald
[sig][/sig]
 
Gerald,

What you are seeing is just my server 500 error file, which is all HTML and has nothing to do with JavaScript. For some reason, the debugger loads it in place of the actual JavaScript. I'm not sure why it is giving that kind of error when the exact same JavaScript codes runs on an NT server and when the JavaScript pasted in exactly as it is will run when called from the HTML files' header when inserted directly.

Don [sig][/sig]
 
Ohhh ok... So thats why I would get that temp.html file when I typed the URL of the .js file directly in the browser.

Ok. Have you tried putting the .js files in a different directory?

Some apache implementations will not allow you to call any non-CGI scripts from the cgi-bin directory.

I know this is the case when somebody accesses one of my sites via SSL, but it is not the case when somebody accesses it with a standard http:// call.

Regards,
Gerald
[sig][/sig]
 
Hi Gerald,

On this site, I can put JS, Perl or anything else just about anywere although I do try to keep everything segregated to make maintenance easier. There are no limitations in that respect. I did try loading the file from the same directory as the HTML just to be sure it wasn't a path problem, but it was also a no-go. I have been trying to get Apache set up on my Windows PC just to see if it misbehaves there too, but haven't been able to get Perl running yet with it so I can load the local copy of the site. If it gives the same error with Apache on my PC, then I'll know if it's an Apache issie. Otherwise it is an issue with the script itself or the Apache Web server's setup.

Thanks!
Don [sig][/sig]
 
have you tried using a really simple one line script on this such as, creating a file called test.js with just the 1 line:

document.write(&quot;hello&quot;);

and calling it from one of your HTML pages?

it really does sound like a configuration problem with apache because the javascript error that you are getting is because when you call the .js file, rather than sending the .js file to your browser for processing, it tries to execute it on the server, and since it wont execute on the server, what it sends to the browser is your error page inside of the <SCRIPT> tags. So you get a syntax error on line 1 because it thinks that your error page is really your .js page. That is also why the error page comes up in the debugger.

You should never get a 500 server error in this case even if your .js file was complete gibberish.

I will try to tinker with my httpd.conf file and see what would cause it. I will let you know if I come up with something.


Regards,
Gerald [sig][/sig]
 
Gerald,

I am loading two separate scripts and one of them is a &quot;one liner.&quot; Even when calling just that one, I get the error. Anything you can suggest with the httpd.conf (or anything else) I can forward to my service provider and they would be happy to impliment it.

Thanks a lot!
Don [sig][/sig]
 
It almost has to be an AddType or AddHandler setup in the httpd.conf file.

The first thing is tell your ISP to search the httpd.conf file for .js and remove every instance of it.

Try doing this. Try changing the name of your .js file to .html and calling it that way.

I dont suppose your ISP would send you a copy of his httpd.conf file?
heh. probably not. but that would be the best way to track it down ;)

Regards,
Gerald



[sig][/sig]
 
Hi Gerald,

I'll forward your information to them. Certainly it couldn't hurt to ask for the httpd.conf file! The worst they caould say is &quot;no.&quot;

Thanks1
Don [sig][/sig]
 
Gerald,

I tried renaming it with an html extension per your suggestion but still get the same error. It was a good idea to try it. Haven't heard from the ISP yet.

Don [sig][/sig]
 
I've just got to ask: why are you calling an external .js file from the /cgi-bin directory? If there is no server-side action that the server is doing to it, why put it in the cgi-bin directory? Generally, as mentioned above, Documents loaded from cgi-bin &quot;are treated as applications and run by the server when requested rather than as documents sent to the client&quot; (from the Apache httpd.conf file).

Thus Apache does not even see the browser as requesting a file, but as trying to execute a script, which it can't execute, because Apache doesn't recognize Javascript. (Unless there is some crazy module I don't know about)

Now as to the second question of why doesn't your script run when you put it in the same directory, that HAS to be a different problem. Have you tried BOTH renaming your external js file to .html AND putting it in the same directory? (If you are loading web pages from there, then there is no reason for it not to load your script) Or, even rename it to .txt, which Apache generally sees as a plaintext file request.

However, there is something funny about your server. When I try to call your file at I get a 302 redirect, NOT a 404 (file not found). Also, in the source to that redirected file (mentioned above) I see a reference to '<script language=&quot;JavaScript&quot; src=&quot;cgi-bin/nodeeplink.js&quot;></script>'. The first time I tried to download your .js file, I mistakenly went to the wrong URL, and was presented with , which mentions that deeplinking is forbidden. All this seems a bit odd and roundabout. Did your ISP tell you to place .js files in cgi-bin? [sig][/sig]
 
Perl, JavaScript, HTML etc. can be anywhere on the server and still work properly. In fact, I created the cgi-bin directory myself years ago and also have two other sites on the same account each with their own. In other words, the cgi-bin is no different than any of the other directories on the system as far as the way it behaves - on this server. I know what you mean because I also have another ISP that is configured the way you describe.

I put the JavaScript files into the cgi-bin directory only because it is convenient to get to from any of the site's other sub-directories.

The 404-1.cgi is just a Perl script linked via the .htaccess file that generates a log entry when someone tries to access a file that doesn't exist. It helps me to find when I have a bad link (in case I delete or move a file, for example) and it tells me when someone else is using an out of date URL to get to the site.

The JavaScript in question is called &quot;secure.js,&quot; though it is just a toy that somewhat supresses right-click popups and causes links directly to sub-pages to return the main URL instead making entry by the front door necessary. The old one was called &quot;nodeeplink.js but I read that external JavaScripts sometimes have problems when they don't have an 8.x file name, so I renamed it. I did miss the one in the Server 500 error document though as I noticed this afternoon.

I hope this answers some of the mysteries and thanks for the reply!

Don [sig][/sig]
 
I see...

Maybe somewhere in here is the key to the problem. The enormous flexibility of Apache can lead to unpredictable results sometimes. Having a setup where CGI can be executed anywhere is one thing, but the question is: what other customizations have been made? It is quite easy to configure Apache to try to execute files of a certain extension rather than serve them to the browser. The only way to know at this point, though, would be to look at httpd.conf, and see what Apache modules are enabled. 'mod_rewrite' comes to mind as a possible suspect.

It would also be interesting to look at the Javascript files to see if anything in there might be misinterpreted as a server-side directive. This reminds me... if you continue to have trouble with this, another work-around would be to use SSI. [sig][/sig]
 
Hi, thanks!

Except for making suggestions to the ISP, I really can't do anything about the way the server is set up. In this case, it made it easy to have more than one site on the same account so was a benefit.

SSI is really not an option. I have hundreds of HTML files and each would have to be renamed with the shtml extension. That would be a nightmare, not to mention cause a slowdown of the site due to all the parsing of each and every file. If it came to that, I would just embed the script into each file which does work - only external files seem to have the problem.

There's nothing magical about the JavaScript. In fact it's pretty basic and is already posted on the JavaScript forum in case there was a problem with it. There were several variations used based on input there, and I searched the Internet and found other ideas, but none made any difference with the problem.

Here's the code as it is in working condition on my NT PWS installation, though I hesitate to post it here on the Apache forum. I do so only because you asked.

The first line does one thing, and the rest together does something else. I tried only the first line by itself too since I read that an external JavaScript file is best when it is only one program. This is technically two, but it made no difference with only the one line.

[tt]if (top == self) self.location.href = &quot;
document.oncontextmenu = function(){return false}
if(document.layers) {
window.captureEvents(Event.MOUSEDOWN);
window.onmousedown = function(e){
if(e.target==document)return false;
}
}
else {
document.onmousedown = function(){return false}
}[/tt]

Don [sig][/sig]
 
Think Im getting dizzy now. heh

Make a copy of the script that you posted above, and remove the first line. Once you have done this let me know the exact URL of the copy.

Im assuming that that is not exactly what you have in your script on the server, because 127.0.0.1 resolves to localhost which is just wrong unless you are viewing the page from the same machine that it is on.

But I think if you take out the first line, I will be able to open it in my debugger correctly and find out where our error is coming from.


Regards,
Gerald




[sig][/sig]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top