Developed application using GWT which contains lot of static files(javascript,css,images) which i want to cache for 30 days. I read lot of blogs but didn't get any clue.
- How to cache static files?
- What are the possible option to achieve caching (do i need to configure in server or GWT application, here i am using glassfish/payara server for deployment)
Any idea?
Note: I want do achieve this with minimal code changes, even i read this Client side caching in GWT
but don't want to go with dispatcher approach
You will need to add something like the ExpiresFilter to your servlet container.
I'm adding the details for the configuration from the link mentioned above just in case the content of the link goes away:
You will need to edit web.xml to add a filter and a filter mapping:
<filter>
<filter-name>ExpiresFilter</filter-name>
<filter-class>server.ExpiresFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>ExpiresFilter</filter-name>
<url-pattern>/images/\*</url-pattern> <!-- these patterns should match cached resources -->
<url-pattern>/resources/\*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
If you need a more portable approach for use in different application servers, you might end up writing a generic servlet Filter like I did.
After all that is no big deal as you just have set the Expires and Cache-Control: max-age headers for HttpServletRequests on your given paths.
As a starter, I stumpled upon this implementation and how Tomcat does it.
Related
I am using 'org.owasp.esapi.waf.ESAPIWebApplicationFirewallFilter' to handle OWASP Top 10 Vulnerabilities. Is it right way to use this approach? and how do I configure waf-policy.xml ?
From the documentation:
This is the main class for the ESAPI Web Application Firewall (WAF).
It is a standard J2EE servlet filter that, in different methods,
invokes the reading of the configuration file and handles the runtime
processing and enforcing of the developer-specified rules. Ideally the
filter should be configured to catch all requests (/*) in web.xml. If
there are URL segments that need to be extremely fast and don't
require any protection, the pattern may be modified with extreme
caution.
To use the filter, add org.owasp.esapi.waf.ESAPIWebApplicationFirewallFilter in the web.xml and add the jar file in project library.
<filter>
<filter-name>ESAPI-WAF</filter-name>
<filter-class>org.owasp.esapi.waf.ESAPIWebApplicationFirewallFilter</filter-class>
</filter>
I am using spring-ws and I have the below configuration in my web.xml
<servlet>
<servlet-name>spring-ws</servlet-name>
<servlet-class>org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class>
<init-param>
<param-name>**transformWsdlLocations**</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>spring-ws</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
Here I have transformWsdlLocations configured. Please explain me the use of transformWsdlLocations here. I am using the dynamic WSDL generation concept.
Is transformWsdlLocations really required for dynamic WSDL generation?
Thanks!
Given that it only takes a couple of minutes to remove the value and redeploy your application, I would advise you to do that and see what happens. Just try accessing the WSDL through "localhost" and through "127.0.0.1", and see what differences there are.
However I'll explain what you should see here...
When you read the WSDL that is generated, you should find that there are URLs in there.
i.e. From the local machine you might use:
http://localhost:8080/myservice.wsdl
But when you go live, your service might be:
http://www.<yourdomain>.com/myservice.wsdl
You don't want someone downloading the WSDL from your production domain to have those values populated with "localhost:8080". Likewise, you can't test your service properly if the URL being returned in the WSDL is for your production server. Or you might have multiple production services with different URLs.
transformWsdlLocations ensures that this is generated dynamically based on whatever URL is being used to access the service.
It is not needed for dynamic WSDL generation, but I have always found it very useful to have it. However, it is not enabled by default, so if you do want those URLs to be generated dynamically then it's best to include it.
I'm using GAE and want to map html file to Filter. I do the following in web.xml:
<filter-mapping>
<filter-name>VerifierFilter</filter-name>
<url-pattern>/test.html</url-pattern>
</filter-mapping>
However, if I access http://localhost/test.html, it seems that filter code is not called at all.
AFAIR GAE doesn't serve static files through the same servlet infrastructure. So that's why your filter isn't applied.
You could try renaming your test.html to test.jsp. That will serve the static file as a jsp and the filter should be applied. However it won't get faster that way, but if performance is not a concern for you, than it might be a viable option.
I've recently run into a snag that will probably keep me from being able to follow through with plans to package a single WAR with two servlets. The work-around is to create an extra Maven WAR module.
Besides the extra hassle for me and for customers, is there any other real drawback? are there advantages?
#Edit
The "snag" I have run into is that I want two different authentication mechanisms for each servlet. One to use Spring Security and the other either a different authentication provider or possibly Basic authentication. See here:
Is it possible to use a different Spring Security AuthenticationProvider in different servlets, same WAR?
The main drawback is that the web application container keeps the separate applications completely apart from each-other. So if they use a common set of jar files (for example), they will each have to load their own version, which takes up a lot of memory. Also, they cannot really communicate with each-other via Session or ServletContext, or request forwarding.
The advantage only comes from situations where you really think of the two WAR as independent applications.
If the two servlets belong together you should put them into the same WAR.
If you are using container based authentication, that is done per webapp I presume. However, if authentication is done in the servlet or through filters, there is no problem having 2 servlets with different authentication mechanisms in the same webapp.
For Spring, it will layer authentication on top off the dispatchservlet mapping. If you are using a filter, make sure it matches the path for each servlet to only auth for that servlet.
<filter>
<filter-name>auth1</filter-name>
<filter-class>...</filter-class>
</filter>
<filter>
<filter-name>auth2</filter-name>
<filter-class>...</filter-class>
</filter>
<filter-mapping>
<filter-name>auth1</filter-name>
<url-pattern>auth1/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>auth2</filter-name>
<url-pattern>auth2/*</url-pattern>
</filter-mapping>
A WAR can contain any number of servlets.
You should really not be having issues with more than one servlet per WAR.
Maybe you could elaborate on your problem with more than one servlet.
I have got an application that is not compatible to work using IE8 browser.
I am looking for a way to to configure Tomcat on which this application run, so the pages could be read by IE8 and treated as if they are IE7 or IE6
By googling so far I found a possible suggestion which say to add to the http response the header:
X-UA-Compatible: IE=EmulateIE7
here
that tell IE8 to be like IE7.
The problem is that this way requires adding a filter that should be added on application level. I'd like to know if any of you is familiar with a more generic way that Tomcat enables to send its http content to be IE7 (or IE6) compatible ?
Download urlrewritefilter-4.0.3.jar from http://tuckey.org/urlrewrite/
Add urlrewritefilter-4.0.3.jar to WEB-INF/lib
Add following code to WEB-INF/web.xml
<filter>
<filter-name>UrlRewriteFilter</filter-name>
<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>UrlRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
Make a new configuration file for the module. (WEB-INF/urlrewrite.xml)
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN" "http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
<urlrewrite>
<rule><condition name="user-agent">.*MSIE.*</condition>
<set type="response-header" name="X-UA-Compatible">IE=EmulateIE7</set>
</rule>
</urlrewrite>
Tomcat is a general purpose webserver and servlet container. It is absolutely browser-agnostic thus, there's no way to configure it in some special way to deal with IEs.
You don't have to add filter really. The bare minimum is to set the response header anywhere in "service" method (or doGet or doPost, whatever application uses):
res.addHeader("X-UA-Compatible", "IE=EmulateIE7 ");
But this is in case when there's a single entry point in the server application. Otherwise filter should do the job in a better way.
See this forum thread that discusses exactly the same situation you are describing. It seems that a filter is the best way to go. As an answer at the above thread suggests, you could use Url Rewrite Filter.
Also, if you are using Apache Web Server to proxy Tomcat, you could easily configure it to add any header to the response.