Re: streaming output

2001-05-17 Thread Dave Liney

 From: Robert Thompson [EMAIL PROTECTED]

  From: Philip Newton [mailto:[EMAIL PROTECTED]]
  At a guess: Content-Encoding: gzip instead.

 Yep that worked,

According to RFC2616 Content-Encoding: x-gzip should have worked as well:

  Use of program names for the identification of encoding formats is not
  desirable and is discouraged for future encodings. Their use here is
  representative of historical practice, not good design. For
  compatibility with previous implementations of HTTP, applications SHOULD
  consider x-gzip and x-compress to be equivalent to gzip and
  compress respectively.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5

Dave.



Re: streaming output

2001-05-16 Thread Philip Newton

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.



RE: streaming output

2001-05-16 Thread Robert Thompson



 From: Philip Newton [mailto:[EMAIL PROTECTED]]
 
 At a guess: Content-Encoding: gzip instead.


Thanks, I'll give that a try.
 
  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.

I was looking at RFC's 2045  2046 which relate directly to MIME. That's
where the Content-Type and Content-Transfer-Encoding headers are talked
about.

Rob


---
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of IBNet
Plc. 

This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.  Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. 

E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses. The sender therefore does not accept
liability for any errors or omissions in the contents of this message which
arise as a result of e-mail transmission. If verification is required please
request a hard-copy version. 




RE: streaming output

2001-05-16 Thread Robert Thompson

 From: Philip Newton [mailto:[EMAIL PROTECTED]]
 At a guess: Content-Encoding: gzip instead.

Yep that worked,

thanks

Rob

-
I must memorise rfc's
I must memorise rfc's
I must memorise rfc's


---
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of IBNet
Plc. 

This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.  Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. 

E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses. The sender therefore does not accept
liability for any errors or omissions in the contents of this message which
arise as a result of e-mail transmission. If verification is required please
request a hard-copy version.