The default path of my app is localhost:8080/myapp .
If I click something on the page which is supposed to redirect me to localhost:8080/myapp/page1 I get 404 back (The requested resource is not available.)
because the actual request made is localhost:8080/page1 .
Fair enough, my RequestMapping is "/page1".
The question is how do I enforce the contextpath as a prefix to all requests ?
What is the best way to deal with this ?
P.S. I don't want to rename my app to Root
I recommend using JSTL.
for example.
LINK
Related
Organizations registering on my application can provide their external websites url for their profile page. The resulting html when displaying the link to their site is example.com (Confirmed by inspecting the page in chrome). When hovering over the link or actually clicking it. The url is apparently interpreted as relative and https://localhost:8443/MyWebApp/profile/ is prepended to it.
Do I have to check and possibly modify links that users input or is there likely something in my configuration that is causing this behavior?
EDIT: Is there a simple method of countering this? Such as a jsp tag or using a url rewriter? (Tuckey)
This is the expected behaviour. Since the provided URL does not begin with a protocol (http, https, ftp, whatever) it is considered relative, and since it does not start with a /, it is considered relative to the current URL.
I configure my error-page in web.xml，for example: <error-page><error-code>404</error-code><location>/error.jsp</location></error-page>。
If I put a URL in browser that does not exits such as http: //localhost:8080/mywebsite/a , it will display the contents of error.jsp.But the URL in browser is not http: //localhost:8080/mywebsite/error.jsp , it is still http: //localhost:8080/mywebsite/a why ? And what to do if make the URL to be error.jsp?
I ask this because I scan this URL using IBM AppScan, it says response status is 200 OK.
There is no point in re-writing the URL to show the user that he/she has hit the error page. In-fact it may expose the structure of your application that may be harmful if you are not too careful.
http://yourhost/something/invalid/url is not much helpful for any malicious user.
But
http://yourhost/pages/errorPages/404Page.jsp
exposes a lot of critical information to the user about the structure of your web-application.
While deploying my app to mochahost, I met the problem between servlet and GWT-RPC communicate. The error shows:
HTTP Status 404 - /403.shtml
type Status report
message /403.shtml
description The requested resource (/403.shtml) is not available.
.war file works perfectly on my workstation, but not working on mochahost.
Any ideas to solve it?
Thanks in advance.
Mochahost have a very good support, try livechatting with their tech department, you will probably have the thing solved.
That's what I do.
Make sure you update live site URL. For instance, generally, on local system you access web app as http://localhost:8080/myapp but, on server it changes to http://[www.]myapp.com. Again, this is just an instance. The point is, the live site must reflect correct URL from code (servlet/JSP/action/etc...) and configuration properties, if any.
Comment 'DirectoryIndex' property in .htaccess file if you do not have any index file.
Comment 'RewriteCond' property in .htaccess file if you do not have any rewrite requirement.
For sure, one of the reason - if client does not accept cookies and servlet does not encode URL.
I'm trying to redirect my response but I got stuck at the link path.
The following command takes me to the tomcat's localhost and searches for the page there but it can't find anything, as expected.
response.sendRedirect("/myPage.html");
In order to manage this problem I have to put my root folder name (the one from webaps) in the link path, but I don't think that's a really good idea.
response.sendRedirect("/mySite/myPage.html");
Why is this happening? Is there any other way to solve this problem, besides getRequestURL() or something like that?
A relative redirect URL is relative to the current request URL (the one as you see in the browser address bar). The leading / will take you to the domain root. The behaviour is perfectly predictable and normal. If the myPage.html is in the same folder as the current request URL, then you can just remove the leading /:
response.sendRedirect("myPage.html");
Or if that is never reliably predictable because the current request URL can come from anywhere in your webapp, then just dynamically include the context path:
response.sendRedirect(request.getContextPath() + "/myPage.html");
Is there anything in the Servlet spec, Tomcat, or Wicket that will allow a webapp running behind mod_proxy to determine the non-proxied URL of the request?
We need to send out emails with links in them. I had been using the following bit of Wicket to construct URLs to specific pages in the app:
String relURL = RequestCycle.get().getRequest().getRelativePathPrefixToWicketHandler();
RequestUtils.toAbsolutePath(relURL);
Since the emails don't go back out through the proxy, of course the URLs don't get re-written, and end up looking like http://localhost/....
Right now the best I can do is to hard-code the URLs to our production server, but that's setting us up for some debugging headaches when running on dev/test machines.
Using InetAddress.getLocalHost().getHostName() isn't really a solution, since that's likely to return prod1.mydomain.com or somesuch, rather than mydomain.dom, from which the request likely originated.
As answered for the question Retain original request URL on mod_proxy redirect:
If you're running Apache >= 2.0.31 then you might try to set the
ProxyPreserveHost directive as described here .
This should pass the original Host header trough mod_proxy into your
application, and normally the request URL will be rebuild there (in
your Servlet container) using the Host header, so the schema location
should be build using the host and path infos from "before" the proxy.
Is there anything in the Servlet spec, Tomcat, or Wicket that will allow a webapp running behind mod_proxy to determine the non-proxied URL of the request?
No. If the reverse proxy doesn't put the information that you require into the message headers before passing them on, there's no way to recover it.
You need to look at the Apache Httpd documentation to figure out how to get the front-end to put the information that you need into the HTTP request headers on the way through. (It can be done. I just can't recall the details.)