When I put below url which exists on Server, I get the 404 error
localhost/PDFDemo/resources/jquery/css/ui-lightness/images/ui-bg_highlight-soft_100_eeeeee_1x100.png
Error 404--Not Found
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.
If the server does not wish to make this information available to the client, the status code `403 (Forbidden)` can be used instead. The `410 (Gone)` status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.
I had same problem for javascript files and resolved the issue by putting below in web.xml
<mime-mapping>
<extension>js</extension>
<mime-type>text/javascript</mime-type>
</mime-mapping>
Are there equivalent codes for jsp and images which I can put in contextConfigLocation(eg : servlet.xml).
The problem is that you are mapping the Spring Dispatcher Servlet to the root context, so Spring wants to handle every request (which isn't in itself a problem if you have it configured correctly). Adding something like this:
<mvc:resources mapping="/resources/**" location="/public-resources/" cache-period="31556926"/>
Modified for your environment should work. See the documentation for allowing static resources to bypass Spring and go to the default servlet here.
You should also add this to your config so that Spring knows to use the Default Servlet.
<mvc:default-servlet-handler/>
Also, answers to this question may help you.
Related
Have searched around and have not found a conclusive answer to this.
I have trying to route all http requests through my dispatcher servlet, and then onto a specific controller. Ultimately I want to be able to handle resource, AJAX and a.n.other request through the central point.
I currently have the url mapping /* in place to do this. My controllers use #RequestMapping("/[My resource].*") to capture my .htm requests. Unfortunately Spring appears to use RequestDispactcher.forward to resolve the .jsp from the InternalResourceViewResolver which is then hitting the front controller again and ultimately causing a 404 error.
My question is, am I able to setup a generic catch all that will handle any HTTP request other than the regular view request ?
The HTTP handler must be able to pass requests on to other servers and resolve internal and external resources e.g. images, css etc.
Regards,
Andy
Regards
A think a better idea is to change the servlet-mapping of DispatcherServlet to / instead of /*, this is because /* makes all request come to this servlet, instead like you have found for the jsp forwards also, inspite of the fact that there is a JSPServlet mapping for the jsps, the / mapping on the other hand will be defaulted to only if a specific mapping is not found for the requested path.
Keep the app servlet mapping to / in web.xml. Like shown below.
<servlet-mapping>
<servlet-name>appServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
To resolve other resources add following tag in your dispatcher servlet xml.
Here resources is the folder containing js, css, images. It is stored under Webcontent folder in maven web application structure. Change it according to your project structure.
<resources mapping="/resources/**" location="/resources/" />
Try this.
I am using IBM WebSphere (WAS) 7.0.0.19 to host a java-based web-app, and I needed to map the extension *.html to a particular servlet so that I could do some server-side scrubbing of user-supplied HTML files. (The server reads the file, augments it with some extra information, and serves up the modified content transparently to the person viewing the page.)
Unfortunately, when I did this, welcome-files stopped working. Previously, if I typed in the URL for a directory, the server would look for index.html and serve up that. Now, I'm just getting a 403 forbidden rule ("Forbidden - by rule."). The access logs don't show anything more--they simply state that directory indexing is forbidden by rule for the server, which is correct. I don't want the webserver to build a table of contents for directories with no index.html, but when there is an index.html, I want it to serve up that file.
My first thought was that it was trying to serve the index.html through my servlet, the servlet was failing to find the file (because the url lacked "index.html"), and therefore it thought there was no index.html. However, I put in some debug code and am quite confident that the servlet code is never getting run when I go simply to the directory itself.
I don't really care whether index.html is served through the servlet or not--in the case of this particular file, the servlet would just spit back the original file anyway. I just want index.html to be served by something.
Here is the relevant section of my web.xml
<servlet-mapping>
<servlet-name>PageScrubber</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
For what it's worth, index.htm and index.jsp were not working before the addition of the servlet mapping. Only index.html worked before. However, now none of them work.
I have used the same web.xml with two Oracle products: WebLogic (WLS) and Oracle Application Server (OAS) with no issues.
I am quite confident that it is just the addition of this scrubber servlet that has caused the problem, because removing that directive caused directory indexing to start working again.
I did find some notes about welcome-file-list not working when using an extended document root, and I tried setting com.ibm.ws.webcontainer.EnablePartialURLtoExtendedDocumentRoot to be true, but that did not seem to change anything.
I'm pretty much out of ideas. Does anyone out there have any thoughts as to why it's not finding my index.html? Thanks in advance!
Caveat: I am working out of memory here.
The Welcome files used to be served by File Serving Servlet (or something that sounds similar to that).
This information would be in the WebSphere extensions file.
I would take a step back and remove your pageScrubber and get the file serving Servlet to serve the welcome files and see that things are working before getting back to using the PageScrubber.
These are my initial thoughts.
HTH
I have this XML in my web.xml file:
<error-page>
<error-code>404</error-code>
<location>/error/html/404</location>
</error-page>
If I go to a page like /indexer (which doesn't exist), then I get redirected properly to the URL /error/html/404. If I go to a page like /index/nope (which also doesn't exist), then I a blank page and the URL reads /index/error/html/404. What can I put in the location tag to always get the correct URL, regardless of where I started?
This is not normal behaviour. It should definitely be relative to the context root. I cite from page 154 of the Servlet 3.0 specification:
The subelement location element contains the location of the resource in the web
application relative to the root of the web application. The value of the location
must have a leading ‘/’.
Your problem is caused by a bug in the servletcontainer used. Report it and/or upgrade to latest version. Or, perhaps you've a bad Filter intercepting on ERROR dispatcher for an URL pattern of /* which is using the RequestDispatcher#forward() wrongly.
Update as per the comments, you're using Tomcat 7.0.16, which is a Servlet 3.0 compatible container. Although your web.xml is declared conform Servlet 2.5 instead of 3.0, I can't reproduce your problem with both web.xml versions on my local Tomcat 7.0.11, 7.0.19 nor 7.0.22. Also, the URL does not change here in browser address bar (and is not supposed to change). Just the original (wrong) URL remains in browser address bar. This makes me think that this is more likely caused by a bad filter or possibly a front controller servlet which is mapped on a too generic URL pattern of /* and is sending a redirect to the wrong URL. Check for such a filter or servlet in your webapp, debug and fix it accordingly.
I'm looking to disable jsessionid from being used in the https headers.
Is there a way to turn this off or disable this being set as a cookie in tomcat 7?
I either want the jsessionid to arrive embedded into a GET method url name value pairs or to be part of a POST request name value pairs.
I know all the advantages and disadvantages of using cookie based sessioning and url rewriting but I have specific needs for specific impl of restful web services.
I need tomcat 7 to accept jsessionid without using the http header: jsessionid.
Thanks.
UPDATE:
so I looked around some more and found this which is implemented using the web.xml conf.
However the following doesn't seem to work with Tomcat 7.
<session-config>
<tracking-mode>URL</tracking-mode>
</session-config>
is it a case of TC7 not fully implementing the servlet 3.0 spec?
The web.xml setting works for me with Tomcat 7.0.20.
Log and check the effective (and maybe the default) session tracking modes:
logger.info("default STM: {}" , servletContext.getDefaultSessionTrackingModes());
logger.info("effective STM: {}" , servletContext.getEffectiveSessionTrackingModes());
Maybe your app override somewhere in the code the session tracking modes. An example:
final Set<SessionTrackingMode> trackingModes =
Collections.singleton(SessionTrackingMode.COOKIE);
servletContext.setSessionTrackingModes(trackingModes);
Check ServletContext.setSessionTrackingModes() calls in your code.
It's also possible to set default session tracking modes in the Tomcat's context settings but I found that web.xml settings override them.
I just got done with a new Web module built with Spring Framework. Till now I was testing all the pages on my local machine using Tomcat. Today after I moved the application to Websphere,
I am getting the following error:
Error 404: No target servlet configured for uri
is there anything I need to do in web.xml or somewhere? I deployed an EAR file on my WAS , which has another war file.
Below is the output I am seeing on the console, if thats any help.
The resource WEB-INF/ibm-web-bnd.xmi that is defined in URI WEB-INF/ibm-web-bnd.xmi for module analytics.war is not valid. The resource has a cross reference org.eclipse.jst.j2ee.webapplication.internal.impl.WebAppImpl#4be44be4 (eProxyURI: WEB-INF/web.xml#WebApp_ID) that cannot be resolved.
[6/17/09 15:24:49:465 CDT] 00000011 ArchiveDeploy W ADMA0091E: The resource WEB-INF/ibm-web-ext.xmi that is defined in URI WEB-INF/ibm-web-ext.xmi for module analytics.war is not valid. The resource has a cross reference org.eclipse.jst.j2ee.webapplication.internal.impl.WebAppImpl#7b7a7b7a (eProxyURI: WEB-INF/web.xml#WebApp_ID) that cannot be resolved.
It looks like you haven't got your servlet configured correctly. I'd say your web.xml has a servlet-name entry that doesn't correspond to a -servlet.xml file in your WEB-INF directory.
I got same error for my json response. This is fixed by setting contentLength in the action.
ibm-web-bnd.xmi has an attribute: fileServingEnabled.
This controls if Websphere is serving static content or not (index.html, pictures, etc.).
It is true, by default if omitted, but you can make sure it is on by adding it to tag WebAppExtension
fileServingEnabled="true"