gzip/zlib media types: The 'application/zlib' and 'application/gzip' Media Types
Standard labels for data compressed with gzip and zlib.
Levine, J., "The 'application/zlib' and 'application/gzip' Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012, <https://www.rfc-editor.org/info/rfc6713>.
@misc{rfc6713,
series = {Request for Comments},
number = 6713,
howpublished = {RFC 6713},
publisher = {RFC Editor},
doi = {10.17487/RFC6713},
url = {https://www.rfc-editor.org/info/rfc6713},
author = {J. Levine},
title = {{The 'application/zlib' and 'application/gzip' Media Types}},
pagetotal = 4,
year = 2012,
month = aug,
} RFC text
Contents
Internet Engineering Task Force (IETF) J. Levine
Request for Comments: 6713 Taughannock Networks
Category: Informational August 2012
ISSN: 2070-1721
The 'application/zlib' and 'application/gzip' Media Types
Abstract
This document defines the 'application/gzip' and 'application/zlib'
media types for compressed data using the gzip and zlib compression
formats.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6713.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
zlib [RFC1950] and gzip [RFC1952] are widely used compression
formats. zlib is a stream format, while gzip adds header and trailer
fields more appropriate for a file format. Both implement the
DEFLATE compression scheme described in [RFC1951].
They are used to compress a wide variety of material, from
unstructured text to structured data to executable code.
Some applications have informally used media types such as
application/gzip-compressed, application/gzipped, application/
x-gunzip, application/x-gzip, application/x-gzip-compressed, and
gzip/document to describe data compressed with gzip. The media types
defined in this document should replace those media types in future
applications.
2. The 'application/zlib' Media Type
The 'application/zlib' media type describes a block of data that is
compressed using zlib [RFC1950] compression. The data is a stream of
bytes as described in RFC 1950.
2.1. Registration Details
Type name: application
Subtype name: zlib
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: Binary
Security considerations: See Section 4 below.
Interoperability considerations: N/A
Published specification: [RFC1950]
Applications that use this media type: anywhere data size is an issue
Additional information:
Magic number(s): first byte is usually 0x78 but can also be 0x08,
0x18, 0x28, 0x38, 0x48, 0x58, or 0x68. The first two bytes, when
interpreted as an unsigned 16-bit number in big-endian byte order,
contain a value that is a multiple of 31.
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information: see
http://www.zlib.net/
Intended usage: COMMON
Restrictions on usage: N/A
Author: John Levine
Change controller: IETF
3. The 'application/gzip' Media Type
The 'application/gzip' media type describes a block of data that is
compressed using gzip [RFC1952] compression. The data is a stream of
bytes as described in RFC 1952.
3.1. Registration Details
Type name: application
Subtype name: gzip
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: Binary
Security considerations: See Section 4 below.
Interoperability considerations: N/A
Published specification: [RFC1952]
Applications that use this media type: anywhere data size is an issue
Additional information:
Magic number(s): first two bytes are 0x1f, 0x8b.
File extension(s): gz
Macintosh file type code(s): N/A
Person and email address to contact for further information: see
http://www.gzip.org/
Intended usage: COMMON
Restrictions on usage: N/A
Author: John Levine
Change controller: IETF
4. Security Considerations
zlib and gzip compression can be used to compress arbitrary binary
data such as hostile executable code. Also, data that purports to be
in zlib or gzip format may not be, and fields that are supposed to be
flags, lengths, or pointers could contain anything. Applications
should treat any data with due skepticism.
Also see the security considerations in the underlying format
documents: Section 5 of [RFC1950], Section 6 of [RFC1951], and
Section 4 of [RFC1952].
5. IANA Considerations
IANA has updated the "Application Media Types" registry to include
'application/zlib' as described in Section 2 and 'application/gzip'
as described in Section 3.
6. Normative References
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, May 1996.
Author's Address
John Levine
Taughannock Networks
PO Box 727
Trumansburg, NY 14886
Phone: +1 831 480 2300
EMail: standards@taugh.com
AI ELI5
On this page
§1Introduction
RFC 6713 registers two standard media types for compressed data: application/gzip and application/zlib. Both use the DEFLATE compression scheme, a widely used algorithm for reducing file sizes.
Before this RFC, applications used non-standard names like application/x-gzip, application/gzipped, or application/x-gzip-compressed. This caused confusion because different systems labeled the same type of compressed data differently. By standardizing on two official media types, applications can now communicate unambiguously about compressed content.
For years, people had made up different names for squeezed files. Now everyone can use the same official names.
§2The Two Media Types
application/zlib labels data compressed with the zlib format, which is designed as a data stream. It includes a header and checksum to detect errors.
application/gzip labels data compressed with the gzip format, which adds more header and trailer fields suitable for files. The first two bytes of gzip data are always 0x1f followed by 0x8b, making it easy for software to recognize.
Both formats implement the same underlying DEFLATE algorithm, so they achieve similar compression ratios. The choice between them is mostly about context: zlib for streaming data between applications, gzip for stored files and web transmission.
zlib is like vacuum packing—fast, simple, meant for moving things around. gzip is like a properly labeled storage box with extra information written on it.
§3Security Considerations
Compressed data can hide malicious content. Data claiming to be gzip or zlib may not actually be, or its format fields could contain anything including hostile executable code. Applications must treat incoming compressed data with caution and validate it before using it.
The underlying compression formats have their own security considerations documented in RFC 1950, RFC 1951, and RFC 1952.
A squeezed box could hide something dangerous inside. Always check what comes out before trusting it.