I am having two JSP files in my main application whereas one is MAIN.jsp and another one is CSS & JS import.jsp file.
MAIN.jsp is the main page of main application.The import.jsp file will import the CSS and JS of partner application in MAIN.jsp file which is used for support the few functionality with main application as partner.
But all the application (Main and Partner) are deployed in same server. So basically the host name of both the application will not change but context root alone will get change.
i have used jsp import tag to import the import.jsp in MAIN.jsp like mentioned below code.
MAIN.jsp
<html>
<head>
<c:import url="resourceImport/import.jsp">
</head>
<body>
</body>
</html>
import.jsp
<html>
<head>
<link url="http://hostName/DifferentContext/example.css" rel="stylesheet" type="test/css">
<script type="text/javascript" src="http://hostName/DifferentContext/sample.js" > </script>
</head>
<body>
</body>
</html>
Currently i have hard coded the partner HTTP URL in import.jsp for load all the resource in MAIN.jsp file. But moving forward we are planing to run the application in HTTP and HTTPS environment.
So how can i make it dynamic way of getting protocol in import.jsp file. I have tried following methods to get the protocol dynamically but its not working.
Method 1:
Removing Protocol and make it relative URL
<head>
<link url="//hostName/DifferentContext/example.css" rel="stylesheet" type="test/css">
<script type="text/javascript" src="//hostName/DifferentContext/sample.js" > </script>
</head>
Method 2
Removing Protocol and Host name and make it relative URL
<head>
<link url="//DifferentContext/example.css" rel="stylesheet" type="test/css">
<script type="text/javascript" src="//DifferentContext/sample.js" > </script>
</head>
So could you please anyone help me to get resolve this issue.
If there is anything that makes it worth to use https (and these days there is), I'd opt for less hassle and just go https everywhere.
No more worries, no accidental information leak and protocol change. Easier maintenance and no later update will inadvertently bring back a wrong protocol link.
Check HSTS as an option to force compliant browsers to not bother with any http connection attempt in the future.
That being said, relative links are another way to stay in the same protocol and probably beneficial: You rarely want to hard code domain names into your applications - Depending on the programming style that you're using in your app, you might want to use page-relative links (../DifferentContext/example.css) or server-relative (/DifferentContext/example.css). Protocol relative is fine as well, but hardcodes the domain name.
Yet another option is to make that location completely configurable. This way you can decide later (provided that you've changed all occurrences to the configured value): ${config.theOtherAppBaseUrl}/example.css. With this, you can try out all the different options yourself and within 10 minutes. And change your mind later, when you come to the conclusion that it's worth to go https everywhere.
(Note: You have an issue in your question's code: The last link refers to //DifferentContext...., which would assume that DifferentContext is a hostname - this is a protocol relative URL)
Related
In an HTML file, are the following two script includes functionally equivalent?
index.html
<script src="file.js"></script>
and
<script src="./file.js"></script>
From what I remember, when files are resolved:
(1) The current directory of the HTML file is used by default for resolving relative paths,
(2) So "file.js" and "./file.js" are resolved using the path/directory of the HTML file.
When I experiment with this, they work the same in my test browser/server, but when it's behind an nginx load balancer with a route it is failing. But I think this is a different issue which would be an entirely different question.
EDIT: The value of the PATH environment variable and the rules for executable files lookup are unrelated to the way that HTML <script src="file.js"> is handled.
While the MDN docs for script are not helpful, this article http://brianvanderplaats.com/2017/01/16/understanding-relative-urls/
covers the issue and explains how relative paths are handled.
How it works
The way a script is handled is not determined by the server but is instead determined by the browser. The browser parses the element and makes an HTTP GET request to ask for the javascript file.
For example, if the following browser page were opened http://host.com/app/dir1/index.html and the following script element was found:
<script src="file.js"></script>
When examined in Chrome's devtools I see that an HTTP GET for the file being sent to the server.
http://host.com/app/dir1/file.js
What the standard says
The HTML standard in 4.3.1 The script element says:
If the element has a src attribute, then the value of that attribute must be resolved relative to the element, and if that is successful, the specified resource must then be fetched, from the origin of the element's Document.
This means relative to the index.html file and then requested via the document's origin which is document.location.origin. NOTE: Technically, the element refers to DOM element but I'm keeping it simple.
If we change the index.html file to include a dot, then we see the same HTML GET is issued. So this:
<script src="./file.js"></script>
Also results to the same HTTP GET being issued:
http://host.com/app/dir1/file.js
Hopefully this clearly that src="file.js" is functionally the same as src="./file.js".
Current is changed when <base> element is used
It is worth noting that if the <base> element exists, then it will be used instead of the current location. For example,
<html>
<head>
<base href="https://just-a-test/dir1/">
<script src="./file33.js"></script>
</head>
<body>... rest not shown
Then the browser will issue an HTTP GET for
https://just-a-test/dir1/file33.js
Another interesting case is when a relative path uses a sub-directory, or dot-dot syntax to get to a parent directory ../images/img1.png.
In both cases, the browser resolves the name and issues and HTTP GET Request for the resource it believes is the correct name. So
<html>
<head>
<base href="https://just-a-test/dir1/">
</head>
<body>
<img src="../images/img1.png"></script>
</body>
</html>
results in an HTTP GET request to the following file.
https://just-a-test.com/images/img1.png
<base> can include filename
Lastly, the <base> element can include a filename such as:
<html>
<head>
<base href="https://just-a-test/dir1/index.html">
</head>
<body>
<img src="img44.png"></script>
</body>
</html>
When this happens, the filename is dropped and only the remaining path is used so in this case an HTTP GET request is made for this file.
https://just-a-test.com/dir1/img44.png
And not the file https://just-a-test.com/dir1/index.html/img44.png.
I bring this case up because a common bug is to leave off the trailing slash and wonder why things are not working. For example,
<html>
<head>
<base href="https://just-a-test/dir1">
</head>
<body>
<img src="img44.png"></script>
</body>
</html>
Results in an HTTP GET Request to
https://just-a-test.com/img44.png
Which might make you think it wasn't working. This happens because dir1 is viewed just like index.html in the previous example and ignored for the purposes of issuing the HTTP GET requests.
Documentation on <base>
The MDN documentation for base is here and the HTML5 standard for <base> is here. My hightlights are:
If the document has no elements, then the browser uses location.href. A base can include a filename.
If multiple elements are used, only the first href and first target are obeyed — all others are ignored.
A base element must have either an href attribute, a target attribute, or both.
The base element has to be put in the <head> element.
The base element does not have a closing tag.
There is no difference between the two from web browser perspective.
However, on *nix systems, for example in shell, file.js would be searched in $PATH, while ./file.js will be searched in current directory.
In a Vue.js project created with Vue CLI (internally using webpack), I implement code splitting and lazy loading with dynamic imports like so:
import(/* webpackChunkName: "my-feature" */ "./my-feature.js");
As a result I get the expected set of files:
dist/myApp.umd.min.js
dist/myApp.umd.min.vendors~my-feature.js (my-feature dependencies)
dist/myApp.umd.min.my-feature.js
The Vue application is built as a library and then used for an existing web site. What I do is include myApp.umd.min.js in <head> (common to all pages), and then in <body> request code I need for that page (for example myApp.umd.min.my-feature.js). Dependencies (myApp.umd.min.vendors~my-feature.js) are automatically requested by the earlier script.
Problem
When I navigate to a page, that uses the Vue app (and specifically my-feature), all 3 of the above files are loaded. That is expected for the first visit, but if I move to a different page and then return, only the first file (myApp.umd.min.js) is loaded from cache. The other ones are loaded from server every time I visit the page.
What approach to take for the lazy-loaded scripts to come from cache once already loaded? Thank you!
So far I have not found anything better than including all the scripts, I need on the page, in its <head> section. Moreover only using <script> tag helped; <link href="..." rel="preload" as="script"> was useless.
Use a version parameter for the script url.
There's a code snippet that showcase this:
<script type="text/javascript" src="myApp.umd.min.js?v=123"></script>
Also this is a valid solution:
<link rel="preload" href="myFont.woff2" as="font"
type="font/woff2" crossorigin="anonymous">
From docs:
A rel value of preload indicates that the browser should preload this resource with the as attribute indicating the specific class of content being fetched. The crossorigin attribute indicates whether the resource should be fetched with a CORS request.
In my html document (which is in the xampp/htdocs directory), I'm using an external .js file. The .js file is in the same directory as my html file. I'm simply trying to use document.write() function and it's not printing anything.
I don't understand what I'm doing wrong. Whats the issue?
HTML file
<!DOCTYPE html>
<html>
<head>
<?php include 'include/head_elements.html'?>
<script type="text/javascript" src="register.js"></script>
</head>
<body>
<h1>Company Account creation</h1>
<div id="registration_menu">
<!--Elements are added and removed dynamically using JS-->
</div>
<script>
hello();
load_element_group("email_verification");
</script>
</body>
</html>
JS file
function hello(){
document.write("Hello world")
}
Internet Explorer's security policy may block certain scripts from running on a local machine.
There are ways to avoid this -- such as by adding the XAMPP website as a trusted location -- but often this gets tricky since the default "Intranet Zone" is auto-configured on a PC and modifying that can have other consequences (different zones assume different settings, such as passing NTLM credentials to local websites).
See also https://stackoverflow.com/a/7038775/3196753
A quick fix often is to add the fully qualified domain name (FQDN) to the URL, but depending on the zone settings, this may still cause issues.
A final solution, and one many developers fall back on, is to actually use a registered DNS address, such as http://localtest.me/, which points back to localhost and should use the "Internet Zone".
As Chris G points out in the comments, this isn't typical. Normally localhost can be used without issue so I've provided an example Local Intranet setting which can cause this:
I can't link my CSS or other files to my HTML. I always get the error:
Failed to load resource: net::ERR_FILE_NOT_FOUND
And the strange thing is it works on the computer of my project partner. How is that possible? We have the same code.
This is the part of my code:
<link href="/css/bootstrap.min.css" rel="stylesheet">
<link href="/css/custom.css" rel="stylesheet">
<script src="/js/jquery.min.js"></script>
<script src="/js/bootstrap.min.js"></script>
<script src="/js/register.js"></script>
<script src="/js/login.js"></script>
It's very difficult to know without seeing your directory structure. But it seems likely that removing the leading / from your file path will solve the issue. I'm willing to bet that you're unintentionally referencing an absolute path instead of a relative one.
<link href="css/bootstrap.min.css" rel="stylesheet">
<link href="css/custom.css" rel="stylesheet">
<script src="js/jquery.min.js"></script>
<script src="js/bootstrap.min.js"></script>
<script src="js/register.js"></script>
<script src="js/login.js"></script>
The leading slash tells that you want to link the files from a root. If you were viewing this page on e.g. http://www.example.com the files will be linked from http://www.example.com/css/bootstrap.min.css, even if your current page is http://www.example.com/folder/folder/page.html.
Since you're only using Windows without webserver, the root is C://. A solution would be to use relative paths instead of absolute paths.
For example:
<link href="css/bootstrap.min.css" rel="stylesheet">
In the previous example the file you link (with relative paths) will be in http://www.example.com/folder/folder/css/bootstrap.min.css if your current page is http://www.example.com/folder/folder/page.html.
Your URLs use absolute paths (i.e. they start with /) which makes them relative to the root of the website.
This is excellent when you want to write links that:
Work anywhere on the website, even if the HTML is shared between pages with different numbers of / in the path segments as your main navigation is likely to be
Work in both a development environment and a production environment
In this case it is failing because your development environment doesn't involve a web server.
You are loading the files into the browser directly from your local hard disk without going through an HTTP server. This makes the root of your website be the root of your hard disk (instead of the folder you are keeping the files in).
The solution: Install an HTTP server and tell your browser to fetch the files from http://localhost.
This will provide other benefits, such as being able to test Ajax code in your development environment.
Is there any way to use ASP.NET's 'web application root' operator ~ in a script tag? If not, is there any way to mimic such behavior?
My application uses nested master pages for different sub directories; A content page uses its directory-specific master page, which uses the root master page. I'd like to be able to include my <script> tags in the root master page, so I'm not repeating code all over the place, but since I don't necessarily know the depth of the path for any given content page, I can't reliably provide paths to the scripts folder.
I considered using paths in the form /scripts/jquery.js, but since the Visual Studio development server starts the application in a subdirectory of the server root, this will not translate well to the live server. To illustrate:
<!-- dev server path -->
<script type="text/javascript" src="/my_project/scripts/jquery.js"></script>
<!-- live server path -->
<script type="text/javascript" src="/scripts/jquery.js"></script>
You can, of course see the issue. Since I am not the only developer on the project, I have very little control over what happens in the "go live" process; otherwise, it could just be a matter of removing /my_project in the "go live" process.
There are some possible cases on that.
1) For large project use the local iis5.1 or other local iis, and not the VS web that runs.
2) You can avoid the first spash and use relative paths... eg:
<script type="text/javascript" src="scripts/jquery.js"></script>
<script type="text/javascript" src="../scripts/jquery.js"></script>
so you do not force him to start from beggining.
3) You can place a literal control there and just render the script tag on Page_Load with the correct path every time
4) and you can just render the src on page
<script type="text/javascript" src="<%=ResolveUrl("~/scripts/jquery.js")%>" ></script>
I am using the 1 and 3.