Using GZIP for HTTP request response compression

What is GZIP?
It is a compression format created by Jean-Loup Gailly and Mark Adler. Version 0.1 was first publicly released on October 31, 1992.
GZIP is based on the DEFLATE algorithm, which is a combination of LZ77 and Huffman coding. DEFLATE was intended as a replacement for LZW and other patent-encumbered data compression algorithms which, at the time, limited the usability of compress and other popular archivers.

Effect of compression on HTTP transport
The time it takes to transfer an HTTP request and response across the network can be significantly reduced by decisions made by front-end engineers. It's true that the end-user's bandwidth speed, Internet service provider, proximity to peering exchange points, etc. are beyond the control of the development team. But there are other variables that affect response times. Compression reduces response times by reducing the size of the HTTP response.
Starting with HTTP/1.1, web clients indicate support for compression with the Accept-Encoding header in the HTTP request. Accept-Encoding: gzip, deflate
If the web server sees this header in the request, it may compress the response using one of the methods listed by the client. The web server notifies the web client of this via the Content-Encoding header in the response. Content-Encoding: gzip
Gzip is the most popular and effective compression method at this time. It was developed by the GNU project and standardized by RFC 1952. The only other compression format you're likely to see is deflate, but it's less effective and less popular.

Order of reduction in request response size
Gzipping generally reduces the response size by about 70%. Approximately 90% of today's Internet traffic travels through browsers that claim to support gzip. If you use Apache, the module configuring gzip depends on your version: Apache 1.3 uses mod_gzip while Apache 2.x uses mod_deflate.

This is just a start. If the request and response are soap based or any other xml protocol, this compression can be more than 90 %.

Issues with Compression

There are known issues with browsers and proxies that may cause a mismatch in what the browser expects and what it receives with regard to compressed content. Fortunately, these edge cases are dwindling as the use of older browsers drops off. The Apache modules help out by adding appropriate Vary response headers automatically.
Servers choose what to gzip based on file type, but are typically too limited in what they decide to compress. Most web sites gzip their HTML documents. It's also worthwhile to gzip your scripts and stylesheets, but many web sites miss this opportunity. In fact, it's worthwhile to compress any text response including XML and JSON. Image and PDF files should not be gzipped because they are already compressed. Trying to gzip them not only wastes CPU but can potentially increase file sizes.
Gzipping as many file types as possible is an easy way to reduce page weight and accelerate the user experience.

Servlet - Handling HTTP request

In the previous few chapters, we learnt what a Servlet is, what a JSP is, how they fit together in the bigger picture in a J2EE Application. In this chapter, we are going to see how Servlets handle HTTP Requests.

So, lets get started!!!

Servlets & Web Pages:

JSP and servlets have greatly enhanced the way in which we can create and manage Web pages. The difficulty level of coding JSP is between that of coding HTML and pure Java. Servlets are pure Java. The idea behind having both is providing a way for non-programmers to contribute functionality through JSP. You can “program” a JSP page almost as easily as you can write an HTML page. For simple tasks like displaying the current date, you write a normal HTML page and add only a small amount of Java as a scriptlet. For big tasks like processing a shopping cart, you use JSP as the mediator between the Web form and a component(s) (bean or servlet) that has all the processing logic. Most of the code in a Web application will go into servlets. The JSP portion is a just front end to the application (with little logic of course) that a user can use/navigate comfortably.

We all know that the web (Internet) lives over the Http protocol. The servlet as expected is handle the http requests. Well, what use would a servlet be if it cannot handle the most commonly used protocol in the internet.

A lot of things happen when a servlet is invoked because of some user action in a web page. The sequence of events starts with a browser sending a request to a Web server. The server hands the request to a Servlet Container. The container loads the servlet (if it isn't already loaded), instantiates a request and response objects, and then hands these objects to the servlet by calling first its init() method, then its service() method, and lastly the destroy() method. The service() method will typically call one of the doXXX() methods such as doGet(). The response based on the output of the doXXX() methods will be sent back to the browser and will be displayed on screen.

Below is a diagrammatic representation of how data flows from a browser to the servlet and then back to the browser.

  Let’s retrace the sequence of steps:

1. Web Server receives request from the Browser (Http Request)
2. Web Server checks the request and invokes the appropriate Servlet/JSP in the Servlet Container
3. If this is the first time the servlet is invoked its init() method gets called
4. If not, the service() gets called.
5. The service() method in turn delegates the processing to one of the doXXX() methods based on the request received
6. The output of the doXXX() methods is sent back to the servlet container
7. The container analyzes the response and formats it appropriately
8. If the response is normal a Http Response is sent back to the client
9. Else, an error response is sent back to the client


Now that we know how the requests makes its way to the servlet and then comes back to the client, lets look at a sample Servlet that will actually compile and produce some output on the browser.

Servlet Source Code:

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class OurFirstServlet extends HttpServlet
{
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
response.setContentType("text/html");

PrintWriter out = response.getWriter();

out.println("< html >");
out.println("< head >");
out.println("< title > A simple servlet. ");
out.println("");
out.println("< body >");
out.println("< h1 >Simple Servlet");
out.println("This is a Anand’s First Servlet");
out.println("< / body >");
out.println("< / html >");
}
}

The above is a simple servlet that doesn't do anything great but still displays something on the browser when invoked.

On invocation, the servlet code runs and the doGet() method will generate a response that would be equivalent to the below HTML code. This response will be sent to the browser which in turn will display the contents on screen.

< html >
< head >
< title > A simple servlet. < / title >
< / head >
< body >
< h1 >Simple Servlet< / h1 >
This is a Kinshuk’s First Servlet
< / body >
< / html >