Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances

The input buffer would need to be 64K to allow for arbitrary COM or APPn

markers, but these are handled specially: they are either saved into allocated

memory, or skipped over by calling skip_input_data(). In the former case,

suspension is handled correctly, and in the latter case, the problem of

buffer overrun is placed on skip_input_data's shoulders, as explained above.

Note that if you provide your own marker handling routine for large markers,

you should consider how to deal with buffer overflow.

Multiple-buffer management:

In some applications it is desirable to store the compressed data in a linked

list of buffer areas, so as to avoid data copying. This can be handled by

having empty_output_buffer() or fill_input_buffer() set the pointer and count

to reference the next available buffer; FALSE is returned only if no more

buffers are available. Although seemingly straightforward, there is a

pitfall in this approach: the backtrack that occurs when FALSE is returned

could back up into an earlier buffer. For example, when fill_input_buffer()

is called, the current pointer & count indicate the backtrack restart point.

Since fill_input_buffer() will set the pointer and count to refer to a new

buffer, the restart position must be saved somewhere else. Suppose a second

call to fill_input_buffer() occurs in the same library call, and no

additional input data is available, so fill_input_buffer must return FALSE.

If the JPEG library has not moved the pointer/count forward in the current

buffer, then *the correct restart point is the saved position in the prior

buffer*. Prior buffers may be discarded only after the library establishes

a restart point within a later buffer. Similar remarks apply for output into

a chain of buffers.

The library will never attempt to backtrack over a skip_input_data() call,

so any skipped data can be permanently discarded. You still have to deal

with the case of skipping not-yet-received data, however.

It's much simpler to use only a single buffer; when fill_input_buffer() is

called, move any unconsumed data (beyond the current pointer/count) down to

the beginning of this buffer and then load new data into the remaining buffer

space. This approach requires a little more data copying but is far easier

to get right.

Progressive JPEG support

------------------------

Progressive JPEG rearranges the stored data into a series of scans of

increasing quality. In situations where a JPEG file is transmitted across a

slow communications link, a decoder can generate a low-quality image very

quickly from the first scan, then gradually improve the displayed quality as

more scans are received. The final image after all scans are complete is