Spring MVC gzip Compression front-end communication String__java

Due to the needs of the project, the data to be transmitted before and after the compression, the use of the compression method is gzip

Gzip compression will compress string into a large push garbled, but this process is transparent to the user, the browser will automatically parse the contents of the compression, so the user sees the normal content.

Using a pure servlet for compression testing is very simple.

Package com.test;
Import java.io.IOException;
Import Java.io.PrintWriter;

Import Java.util.zip.GZIPOutputStream;
Import javax.servlet.ServletException;
Import Javax.servlet.annotation.WebServlet;
Import Javax.servlet.http.HttpServlet;
Import Javax.servlet.http.HttpServletRequest;

Import Javax.servlet.http.HttpServletResponse;
	@WebServlet ("/test") public class Test extends HttpServlet {private static final long serialversionuid = 1L;  protected void doget (HttpServletRequest request, httpservletresponse response) throws Servletexception, IOException {//
		
		TODO auto-generated Method Stub response.setcharacterencoding ("Utf-8");
		Request.setcharacterencoding ("GBK"); 
		 Response.setcontenttype ("TEXT/HTML;CHARSET=GBK");  
		
		Response.AddHeader ("content-encoding", "gzip");		
		
		 
		PrintWriter out=new PrintWriter (New Gzipoutputstream (Response.getoutputstream ()));
		PrintWriter Out=response.getwriter ();
		
		Out.write ("hahaha haha");  Out.close ();
		
	It's important to remember this sentence, or else you can't show it.	
	} protected void DoPost (HttpServletRequest request, httpservletresponse response) throws Servletexception, IOException
	{doget (request, response);
 }

}

Browser Open F12 Direct access

You can see the use of gzip compression, length (PS: Uncompressed length is 10, interested can try it)

So small text compression, not necessarily an advantage

Maybe some people say, I just want to see what he compressed into what kind of, can!! Just to install a software Fidder

Open the software and visit once again

This time can be seen after the compressed data, but our browser to compare the intelligence, automatically help you unpack again, so transparent to the user

The next switch to the focus, now with a pure servlet development of less people, we all like to use the framework, take the more popular springmvc distance, basically make annotations

The note that transmits text to and from the front and back ends is @responsebody

With this annotation, return directly to string, and the returned content will be displayed on the browser

Why is the function on the previous annotation able to do it? Think about it, the SPRINGMVC takes over Response.getoutputstream (), automatically fills the string with the contents, and then the front end can see

The problem is that we use gzip compression, we need to package response.getoutputstream (), two conflicts

If you still write like a pure servlet, you will get an error: The magic number in the GZIP header is incorrect. Make sure you are passing in the GZip stream

In fact, we can change a train of thought, Springmvc took over Response.getoutputstream (), but Springmvc also in Tomcat inside run Ah,

Directly to tomcat modification is OK. Try it.

And as long as you modify a file, the other code does not need to be modified to remain the same

Just modify%tomcat_home%/conf/server.xml to find the following tags to add the following:

<connector port= "protocol=" http/1.1 "connectiontimeout=" 20000 "redirectport=   
           " 8443 "executor="   
           Tomcatthreadpool "uriencoding=" Utf-8 "   
                       compression=" on "   
                       compressionminsize=" "nocompressionuseragents=" Gozilla, Traviata "   
                       

This time with a string of large string to test

Open the Fidder, open the effect:

If not compressed, see how big:

Compressed from 3232byte to 1088 byte compressed 2/3

The effect is still very good.