|
Hi,
I have installed tomcat 7.0.27 on Windows Home premium 32 bit system with JDK 1.6.32. The tomcat is running successfully as service.I can access the home page of tomcat along with manager application. I deployed my application war file via manager application.The war file was pulled from netbeans dist folder. Now when I access my this application via IE,I do below steps, 1. I open this http://localhost:8082/xxx/index.jsp in IE. it works fine, In index page I have several links, for example testservice.jsp 2. so when I click on testservice link, it looks like http://localhost:8082/xxx/testservice.jsp in address bar and page opens fine in IE.No issues in IE. Now the real problem comes when I try to repeat the steps in Firefox and chrome, Step 1 works fine,no issues everything works as expected and index page comes up,but when it comes to step 2, the address changes to http://localhost:8080/xxx/testservice.jsp . now I am not sure as why FF /Chrome are not sticking to the same ports as IE. I have 8080 tied up with netbean and it has Tomcat 7.0.11 but its not running as service. Also I have static custom error page 404 which resolves correctly in 7.0.27 in all three browsers. Can some one tell me what that I am missing now ? PS: This is how I have links in index page, <li><a href='testservice.jsp'>testservice</a></li> and all jsp resides in web pages folder.I know this gives direct access to JSP and is bad practice,but thats the seperate task to do in my list. - Kiran --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
Sorry fixed it, it was my fault. Base tag was pointing to 8080.Make
sense now. On 5/15/2012 5:27 AM, Kiran Badi wrote: > Hi, > > I have installed tomcat 7.0.27 on Windows Home premium 32 bit system > with JDK 1.6.32. The tomcat is running successfully as service.I can > access the home page of tomcat along with manager application. > > I deployed my application war file via manager application.The war > file was pulled from netbeans dist folder. > > Now when I access my this application via IE,I do below steps, > > 1. I open this http://localhost:8082/xxx/index.jsp in IE. it works > fine, In index page I have several links, for example testservice.jsp > > 2. so when I click on testservice link, it looks like > http://localhost:8082/xxx/testservice.jsp in address bar and page > opens fine in IE.No issues in IE. > > Now the real problem comes when I try to repeat the steps in Firefox > and chrome, > > Step 1 works fine,no issues everything works as expected and index > page comes up,but when it comes to step 2, the address changes to > > http://localhost:8080/xxx/testservice.jsp . > > now I am not sure as why FF /Chrome are not sticking to the same ports > as IE. > > I have 8080 tied up with netbean and it has Tomcat 7.0.11 but its not > running as service. > > Also I have static custom error page 404 which resolves correctly in > 7.0.27 in all three browsers. > > Can some one tell me what that I am missing now ? > > PS: This is how I have links in index page, > > <li><a href='testservice.jsp'>testservice</a></li> > > > and all jsp resides in web pages folder.I know this gives direct > access to JSP and is bad practice,but thats the seperate task to do in > my list. > > - Kiran > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
Kiran Badi wrote:
> Sorry fixed it, it was my fault. Base tag was pointing to 8080.Make > sense now. Personal opinion : <Base> tags are evil. They create all kinds of issues when you move the app, or change your server configuration. There shouldn't be any real reason to use them, if your app is structured properly. Relative paths should work. > > On 5/15/2012 5:27 AM, Kiran Badi wrote: >> Hi, >> >> I have installed tomcat 7.0.27 on Windows Home premium 32 bit system >> with JDK 1.6.32. The tomcat is running successfully as service.I can >> access the home page of tomcat along with manager application. >> >> I deployed my application war file via manager application.The war >> file was pulled from netbeans dist folder. >> >> Now when I access my this application via IE,I do below steps, >> >> 1. I open this http://localhost:8082/xxx/index.jsp in IE. it works >> fine, In index page I have several links, for example testservice.jsp >> >> 2. so when I click on testservice link, it looks like >> http://localhost:8082/xxx/testservice.jsp in address bar and page >> opens fine in IE.No issues in IE. >> >> Now the real problem comes when I try to repeat the steps in Firefox >> and chrome, >> >> Step 1 works fine,no issues everything works as expected and index >> page comes up,but when it comes to step 2, the address changes to >> >> http://localhost:8080/xxx/testservice.jsp . >> >> now I am not sure as why FF /Chrome are not sticking to the same ports >> as IE. >> >> I have 8080 tied up with netbean and it has Tomcat 7.0.11 but its not >> running as service. >> >> Also I have static custom error page 404 which resolves correctly in >> 7.0.27 in all three browsers. >> >> Can some one tell me what that I am missing now ? >> >> PS: This is how I have links in index page, >> >> <li><a href='testservice.jsp'>testservice</a></li> >> >> >> and all jsp resides in web pages folder.I know this gives direct >> access to JSP and is bad practice,but thats the seperate task to do in >> my list. >> >> - Kiran >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 André, On 5/15/12 5:00 AM, André Warnier wrote: > Personal opinion : <Base> tags are evil. They create all kinds of > issues when you move the app, or change your server configuration. > There shouldn't be any real reason to use them, if your app is > structured properly. Relative paths should work. +1 I only just found out in the last few months that URIs within a CSS are /relative to the URI of the CSS/ which blew my mind and, honestly, makes total sense. I can't see a really good reason to use a <base> tag these days unless you want fully-qualified paths for all URLs and want to save on bandwidth or something like that. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+yY08ACgkQ9CaO5/Lv0PBL2wCcDBUNu34wsterX9H04J7w6i83 qCIAoIWEl5cqol+IVQFiR+6buPBNuEdJ =i1oU -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
On 15/05/2012 15:08, Christopher Schultz wrote:
> On 5/15/12 5:00 AM, André Warnier wrote: >> Personal opinion :<Base> tags are evil. They create all kinds of >> issues when you move the app, or change your server configuration. >> There shouldn't be any real reason to use them, if your app is >> structured properly. Relative paths should work. > +1 > > I only just found out in the last few months that URIs within a CSS > are /relative to the URI of the CSS/ which blew my mind and, honestly, > makes total sense. A JSP developer needs to know how (and when) references are resolved in at least these cases: <%@ include file="foo" ... <%@ include file="/foo" ... <%@ page errorPage="foo" ... <%@ page errorPage="/foo" ... <%@ taglib uri="foo" ... <%@ taglib uri="/foo" ... <jsp:forward page="foo" ... <jsp:forward page="/foo" ... <jsp:include page="foo" ... <jsp:include page="/foo" ... <link href="foo" ... <link href="/foo" ... <script src="foo" ... <script src="/foo" ... <img src="foo" ... <img src="/foo" ... <style type="text/css"> p { background:url(foo) } ... <style type="text/css"> p { background:url(/foo) } ... [surely there are more, e.g. within in-page JavaScript?] What *nix minds think of as an "absolute" path e.g. /foo is just relative to something other than what foo is relative to. I'll try to find a small prize for whoever is first to provide links to clear, definitive documentation of how each case above resolves ;-) > I can't see a really good reason to use a<base> tag these days unless > you want fully-qualified paths for all URLs and want to save on > bandwidth or something like that. We found one, but if you are just using <base> empirically, to make things work when you don't really understand "relative paths", then it's probably worth time spent figuring out how to manage without it. Paul Singleton --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Paul, On 5/15/12 11:05 AM, Paul Singleton wrote: > On 15/05/2012 15:08, Christopher Schultz wrote: > >> On 5/15/12 5:00 AM, André Warnier wrote: > >>> Personal opinion :<Base> tags are evil. They create all kinds >>> of issues when you move the app, or change your server >>> configuration. There shouldn't be any real reason to use them, >>> if your app is structured properly. Relative paths should >>> work. > >> +1 >> >> I only just found out in the last few months that URIs within a >> CSS are /relative to the URI of the CSS/ which blew my mind and, >> honestly, makes total sense. > > A JSP developer needs to know how (and when) references are > resolved in at least these cases: > > <%@ include file="foo" ... <%@ include file="/foo" ... > > <%@ page errorPage="foo" ... <%@ page errorPage="/foo" ... > > <%@ taglib uri="foo" ... <%@ taglib uri="/foo" ... > > <jsp:forward page="foo" ... <jsp:forward page="/foo" ... > > <jsp:include page="foo" ... <jsp:include page="/foo" ... All of the above should be covered in great detail in the JSP specification. They are interpreted 100% on the server side. http://jcp.org/aboutJava/communityprocess/mrel/jsr245/index.html > <link href="foo" ... <link href="/foo" ... > > <script src="foo" ... <script src="/foo" ... > > <img src="foo" ... <img src="/foo" ... All of the above will be (according to HTML) relative to the currently-displaying page's URL (back to the last / in the first example in each) or relative to the host (in the examples starting with /). They are interpreted 100% by the client. http://www.w3.org/TR/WD-html40-970917/htmlweb.html > <style type="text/css"> p { background:url(foo) } ... <style > type="text/css"> p { background:url(/foo) } ... If this is in page markup (as you have here), then the URLs behave exactly as described above for the HTML rules. If they are in a separate CSS file, then all URLs are relative to the URL of the CSS file itself. Any relative URL on a page that contains a <base> tag will be relative to the base tag's URL instead of the current page's URL. http://www.w3.org/TR/css3-values/#url > [surely there are more, e.g. within in-page JavaScript?] In-page Javascript follows the same rules as everything in the HTML, since you are manipulating DOM elements which follow HTML rules. If you ask an element for its URL and then try to, say, open an XMLHttpRequest to it, I don't know if the fully-qualified URL is used, or if the browser resolves the URL relative to the current page. I suspect that the latter is true, the result is the same, and it just works as one would expect. > What *nix minds think of as an "absolute" path e.g. /foo is just > relative to something other than what foo is relative to. URLs beginning with / *are* relative. Absolute URLs must include the protocol, etc. and so generally (on the web) begin with http(s)://. > I'll try to find a small prize for whoever is first to provide > links to clear, definitive documentation of how each case above > resolves ;-) Give the prize to Google. It's very good at finding things like "html relative url" and "css relative url" and "jsp 2.2 specification". >> I can't see a really good reason to use a<base> tag these days >> unless you want fully-qualified paths for all URLs and want to >> save on bandwidth or something like that. > > We found one Please explain. I'd love to hear it. > but if you are just using <base> empirically, to make things work > when you don't really understand "relative paths", then it's > probably worth time spent figuring out how to manage without it. +1 Using the <base> tag is just likely to mask other problems in your webapp. Also, <base> doesn't work on the server ;) - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ydjcACgkQ9CaO5/Lv0PAT6gCgrfOjTLnGA2oiQ8v4aYgWPt2R fwYAn3T8EgIRS+aYCGQL4RoBYoEsi0Vt =+tP+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
In reply to this post by Paul Singleton
Paul Singleton wrote:
> On 15/05/2012 15:08, Christopher Schultz wrote: > >> On 5/15/12 5:00 AM, André Warnier wrote: > >>> Personal opinion :<Base> tags are evil. They create all kinds of >>> issues when you move the app, or change your server configuration. >>> There shouldn't be any real reason to use them, if your app is >>> structured properly. Relative paths should work. > >> +1 >> >> I only just found out in the last few months that URIs within a CSS >> are /relative to the URI of the CSS/ which blew my mind and, honestly, >> makes total sense. > > A JSP developer needs to know how (and when) references are resolved in > at least these cases: > > <%@ include file="foo" ... > <%@ include file="/foo" ... > > <%@ page errorPage="foo" ... > <%@ page errorPage="/foo" ... > > <%@ taglib uri="foo" ... > <%@ taglib uri="/foo" ... > > <jsp:forward page="foo" ... > <jsp:forward page="/foo" ... > > <jsp:include page="foo" ... > <jsp:include page="/foo" ... > > <link href="foo" ... > <link href="/foo" ... > > <script src="foo" ... > <script src="/foo" ... > > <img src="foo" ... > <img src="/foo" ... > > <style type="text/css"> p { background:url(foo) } ... > <style type="text/css"> p { background:url(/foo) } ... > > [surely there are more, e.g. within in-page JavaScript?] > > What *nix minds think of as an "absolute" path e.g. /foo is just > relative to something other than what foo is relative to. > > I'll try to find a small prize for whoever is first to provide links to > clear, definitive documentation of how each case above resolves ;-) Well, if you are willing to up the prize a little bit (like to "medium" or so), here is my entry for an empirical set of rules : The first and most important aspect to consider is *who* has to resolve these references. And in your examples above, there are clearly two totally distinct cases : a) a "<%@ include" kind of tag is processed by the server software, before the page is sent to the browser. So in this case, the server software has to have a point of reference on the server, to resolve them. The browser will never see those tags, as they will have been replaced by generated HTML before they are sent out. b) the other cases which you mention are tags which "persist" in the pages sent to the browser, and thus it is the browser who will have to resolve them. I will start with those. When the browser resolves such a reference, its "point of reference" is the current document, or rather the URL from which this current document was obtained. (Unless you changed it explicitly using a <base> tag - which is why they are evil..) ... Oh well, I see that Christopher beat me to it, and I agree 100% with his notes. Jeez he types fast.. So I guess I've missed the prize. > >> I can't see a really good reason to use a<base> tag these days unless >> you want fully-qualified paths for all URLs and want to save on >> bandwidth or something like that. > > We found one, but if you are just using <base> empirically, to make > things work when you don't really understand "relative paths", then it's > probably worth time spent figuring out how to manage without it. > > Paul Singleton > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
| Powered by Nabble | Edit this page |
