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");
Related
I have a url which is not working when i tried hitting it directly, but it works when I append /# to the url.
But for QA when I hit the url it is working where it automatically adding the /# and goes to required login page. In QA it was manually deployed not through VSTS pipeline
Actual url(not Working): https://<applicationurl>.azurewebsites.net
URL(working one): https://<applicationurl>.azurewebsites.net/#
Deployment: VSTS build and release
Hosting: Azure App Service
Application: Java, Angular6
In Java a URI of the form "http://x.y.z" has a null path.
A URI of the form "http://x.y.z/" has an absolute path which is "/".
Some browsers will automatically correct an URL by appending "/" if the URL does not have a path, but programmatic interfaces and servers may not.
I suspect that what you describe is just a user error - you need to make sure the input URL has a path. This is what happens when you append "/#" - but I don't think the # makes any difference (that's just adding an empty fragment).
We use AWS to store aduio/video content for our website.
We us the Signed Cookies Using a Canned Policy:
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-setting-signed-cookie-canned-policy.html
So we have 3 cookies set for each request to retrieve the data:
CloudFront-Policy;
CloudFront-Signature;
CloudFront-Key-Pair-Id;
And it is used to access a resource URL like http://cloudfront.org_name.com/2016%2F7%2F1%2FStanding+Meditation_updated+91615.mp3
All three cookies are set by the server (Java-based) for each request anew to a correct pre-set value.
It all works most of the time for most of the content, but for some resources it just fails with a 403 Forbidden error.
If I open two contents (one working, one not) in separate browser tabs, all the cookies and the rest look exactly the same, except for the resource URL.
And yet - one works, while the other does not.
What is even more confusing, sometimes the same resource requested from the same physical client machine, once in FF, other time in Chrome, works in one browser but fails in other one.
Also, sometimes clearing user browser cookies works, the other time it fails, with no discernible pattern.
It's been driving me insane as I struggle to see what's wrong.
Can anyone provide any insight as to what the reason could be and what remedies could be tried?
Okay, the answer is in my reply to Michael:
I noticed later on that the resource URLs for working and failing content were different. Pretty close to not spot the difference on the first sight, but diffrent. Everything was the same - cookes, headers, other parameters. But I was comparing 2 different contents. First URL always worked, second always failed.
Lesson learnt: carefully curl the two resources and analyse the uRLS to see what actually is different.
A tip: use Chrome's development tools to derive curl commands:
Right click on the failing URL -> Copy-> Copy as cURL. Then paste in command line to test.
BTW, we just re-uploaded the failing resource and updated the referring web page - everything works again.
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.
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
I'm just doing a java tomcat project, that does some query in a database then return the file path of some web pages.
Now I have mapped my only class in web.xml and the webapp does return a list of urls which correspond to some html pages in my local disk. I set up a side frame in the webapp, my idea is that I output the results in the output page like "file:///file_path_of_html_page" and when this link is clicked, the side frame will show the html page.
But actually I got the right links but when I click on them, nothing happens, chrome tells me "Not allowed to load local resource". Even I set the target="_blank", the link doesn't work. But the "file:///filepath" are all ok when I type them in the address bar. I've moved all the html pages in the eclipse project folder but that didn't help.
Any suggestions to do this simple task?
The average browser disallows due to security reasons opening file:// resources when the parent resource is by itself served over http://. If you make them fullworthy http:// links, then it will work properly.
Even if the browser allowed it, this approach would not going to work when you publish the webapp on a different server. A file:// resource refers to the local disk file system, which is the one the client (the user with the webbrowser) is using. This is normally in a physically different machine. The client should have a copy of exactly those resources on its own local disk file system beforehand in order to get the file:// links to work.
Just put the HTML pages in public web root of your web project (there where you normally put your JSP files and so on) and use (relative) http:// links to refer the HTML pages. For example, the following link in a http://localhost:8080/contextname/some.jsp
link to some html file
would open the http://localhost:8080/contextname/some.html file.