HTTP-Content encoding

HTTP applications sometimes need to encode content before they are sent. For example, a server might compress a large HTML document before it is sent to a client over a slow connection, which can help reduce the time it takes to transfer the entity.

Content encoding Process

The process of content encoding is described below.

1. The Web server generates the original response message, which has the original content-type and Content-length headers.
2. The Content-Encoding server (which may also be the original server or the downstream agent) creates the encoded message with the same content-type but Content-length may be different (for example, the subject is compressed). The content encoding server adds the content-encoding header to the encoded message so that the receiving application can decode it.
3. The receiving program obtains the encoded message, decodes it, and obtains the original message.

Content encoding Type

HTTP defines a number of standard content encoding types, and allows additional encodings to be added in the form of extended encodings. The code is standardized by the Internet Number Distribution Agency (IANA), which assigns a unique code name to each content encoding algorithm. The content-encoding header uses these standardized codes to illustrate the algorithm used in encoding.

The following table lists some of the commonly used content encoding codes:

	Describe
Gzip	Indicates that the entity is using the GNU ZIP code
Compress	Indicates that the entity is using Unix's file compression program
Deflate	Indicates that the entity is compressed using zlib format
Identity	Indicates that the entity is not encoded. When there is no content-encoding header is, it is implied that this situation

gzip, compress, and deflate codes are lossless compression algorithms that reduce the size of transmitted messages without causing loss of information. Of these algorithms, Gzip is usually the most efficient and most widely used.

Accept-encoding Header

We do not want the server to encode the content in a way that the client cannot decode. In order for the encoding server to use encoding that is not supported by the client, the client places its supported content encoding list in the accept-encoding header of the request, and the server can assume that the client can accept any encoding (equivalent to sending accept-encoding: *).

Content encoding and Content-length

If the subject is content encoded, the Content-length header describes the byte length of the body after encoding (encoded), not the original body length that was not encoded. The following example illustrates this problem.

1. In Servert, the response content is compressed using GIZP.

protected voidDoget (httpservletrequest req, HttpServletResponse resp)throwsservletexception, IOException {Try{String Data= "abcdefghijklmnopqrstuvwxyz\r\n" + "abcdefghijklmnopqrstuvwxyz\r\n" + "ABCDEFGHIJKLMNOPQR stuvwxyz\r\n "+" abcdefghijklmnopqrstuvwxyz\r\n "+" abcdefghijklmnopqrstuvwxyz\r\n "; Bytearrayoutputstream bout = new  bytearrayoutputstream (); Gzipoutputstream Gout = new  gzipoutputstream (bout);        Gout.write (Data.getbytes ());                Gout.close (); byteCompresseddata[] =Bout.tobytearray (); Resp.setheader ( "content-encoding", "gzip ");    Resp.getoutputstream (). write (Compresseddata); } Catch(Exception e) {e.printstacktrace (); }        }

2. Send a request to view the response message. As can be seen from the following request results, the browser decodes the encoded content and displays it, and the value of content-length is not the length of the original content of 140, but the length of the encoded content 51.

HTTP-Content encoding