Reputation: 302
In a HTTP response, a Content-Encoding header field can be bzip2 or x-bzip2
For example, you may get something like
HTTP/1.1 200 OK
Date: mon, 9 Mar 2016 22:38:34 GMT
...
Content-Encoding: bzip
or something like
HTTP/1.1 200 OK
Date: mon, 9 Mar 2016 22:38:34 GMT
...
Content-Encoding: x-bzip
What is the difference between them?
Upvotes: 1
Views: 1328
Reputation: 6606
There is really none. As you can see in the IANA Content Coding Registry, bzip2
and x-bzip2
are no registered content codings. The preceding x-
has been meant to stress out the unregistered nature of this coding (see also x-gzip
vs. gzip
). Interestingly, this pre-dates even RFC1945. RFC1521, section 5 states:
Implementors may, if necessary, define new Content-Transfer-Encoding values, but must use an x-token, which is a name prefixed by "X-" to indicate its non-standard status, e.g., "Content-Transfer-Encoding: x-my-new-encoding".
As far as support for it goes: To my knowledge Lighttpd is the only webserver with support for bzip2. I know for sure that elinks understands bzip2'ed content, but there should be others.
It is rather rare to see any actual use of this coding, as bzip2 is quite CPU-heavy and gzip is offering a better compromise between speed and compression ratio.
Upvotes: 1
Reputation: 1413
It appears that the difference is just that "bzip2" is the actual format, and "application/x-bzip2" is the MIME type. In other words, it's poh-tay-toh / poh-tah-toh -- they're the same thing.
wikipedia link to archive formats
Upvotes: 1