Robert Thompson wrote:
print Content-Type: application/octet-stream\n;
print Content-Transfer-Encoding: x-gzip\n\n;
At a guess: Content-Encoding: gzip instead.
I've had a look at the relevant rfc's.
Which ones? RFC 2616 (HTTP/1.1) mentions gzip not x-gzip under 3.5
Content Codings and 3.6 Transfer Codings.
The main thing I'm unsure about is the
content-transfer-encoding type. Anyone know where there's
a list of them?
RFC 2616 says (section 3.5, Content Codings):
3.5 Content Codings
Content coding values indicate an encoding transformation that has
been or can be applied to an entity. Content codings are primarily
used to allow a document to be compressed or otherwise usefully
transformed without losing the identity of its underlying media type
and without loss of information. Frequently, the entity is stored in
coded form, transmitted directly, and only decoded by the recipient.
content-coding = token
All content-coding values are case-insensitive. HTTP/1.1 uses
content-coding values in the Accept-Encoding (section 14.3) and
Content-Encoding (section 14.11) header fields. Although the value
describes the content-coding, what is more important is that it
indicates what decoding mechanism will be required to remove the
encoding.
The Internet Assigned Numbers Authority (IANA) acts as a registry for
content-coding value tokens. Initially, the registry contains the
following tokens:
gzip An encoding format produced by the file compression program
gzip (GNU zip) as described in RFC 1952 [25]. This format is a
Lempel-Ziv coding (LZ77) with a 32 bit CRC.
[snip]
There's also a transfer encoding of gzip, which must also have chunked,
but that seems to be something different.
See also sections 14.11 Content-Encoding (HTTP response header) and 14.41
Transfer-Encoding (HTTP response header). Transfer encoding differs from
the content-coding in that the transfer-coding is a property of the message,
not of the entity, whatever that means. There doesn't seem to be a
Content-Transfer-Encoding, as in MIME[1]. The RFC also notes that Many
older HTTP/1.0 applications do not understand the Transfer-Encoding header.
[1] though section 3.6 notes that:
Transfer-codings are analogous to the Content-Transfer-Encoding
values of MIME [7], which were designed to enable safe transport of
binary data over a 7-bit transport service. However, safe transport
has a different focus for an 8bit-clean transfer protocol. In HTTP,
the only unsafe characteristic of message-bodies is the difficulty in
determining the exact body length (section 7.2.2), or the desire to
encrypt data over a shared transport.
I would have expected there to be a list somewhere under
ftp://ftp.isi.edu/in-notes/iana/assignments , but the file
transfer-encodings there just points to
http://www.iana.org/assignments/transfer-encodings , which only has 7bit,
8bit, binary, quoted-printable, base64 as possible values.
Any help, pointers much appreciated.
Hope this helps some.
Cheers,
Philip
--
Philip Newton [EMAIL PROTECTED]
All opinions are my own, not my employer's.
If you're not part of the solution, you're part of the precipitate.