When the web server returns a JPEG image (mime type image / jpeg), how is it encoded?

Question

If you make an HTTP request to a web server and return a response like image / jpeg, how are the binary data actually encoded? Is this the original byte level content of the image passing through the wire, or some of its character representation (e.g. base64)?

Answer 1

The encoded transmitted data is indicated by the HTTP Content-Encoding response header (see HTTP 1.1 specifications in RFC2616 section 14.11 and 3.5), if present, it can be gzip , compress or deflate data compress (there are no other parameters in HTTP 1.1). If not, the data is encoded based on the Content-Type HTTP response header (MIME type). Content-Encoding determined by the Accept-Encoding HTTP request header value and whether the web server supports the requested encoding.

In your case, if the Content-Encoding HTTP response header is missing, the data is exactly the same as the contents of the file. Otherwise, it is compressed with the specified encoding. for example: GZip or Deflate.

Answer 2

Source bytes are sent via wire.

(With a few settings, you can confirm this with Wireshark, tcp_dump, etc.)

Note that most servers are not configured for JPEG compression, but this text data is usually sent compressed.

Answer 3

Strange, this is not "straight."

Besides adding a MIME header, the web server seems to highlight all jpeg tokens (0xFF, 0xNN), but leaves the rest intact. This seems strange since I don’t know how the web browser recognizes the beginning of the image frame.

I found this by writing my simple web server on the embedded system - I thought I would need to add the MIME header and send the rest of the jfif-jpeg file intact, but the browser says: “Image cannot be displayed because it contains errors”!

here is the beginning of the original jpeg / jfif in hex

ff d8 ff e0 00 10 4a 46 49 46 00

[SOI] [APP0] [length] JF i F NULL

According to specification.

The resulting file contains this, after the header:

0d 0a 0d 0a 00 10 4a 46 49 46 00

The first 4 bytes are cr / lf / cr / lf at the end of the header, then NO markers, but it contains a data field. The same thing is repeated for other markers, for example. start of frame.

Strange, huh? I don't think this is a mime coding problem, as the rest of the data looks intact - including FF in the data, etc.

Does anyone know what is going on here? PS, to get a closer look, just ask .jpg from any site, using putty or the like, and save what you get and compare it with the original or even with the saved version.