httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: AddOutputFilter hook needed?
Date Tue, 19 Sep 2000 19:13:14 GMT

In a message dated 00-09-19 17:47:43 EDT, Tony writes..

> ...In fact, the RFC says:
> >  7.2.1 Type
> >    When an entity-body is included with a message, the data type of that
> >    body is determined via the header fields Content-Type and Content-
> >    Encoding. These define a two-layer, ordered encoding model:
> > 
> >        entity-body := Content-Encoding( Content-Type( data ) )

That part of the RFC has always been misleading.
It should really read like this...

> >    When an entity-body is included with a message, the presentation 
> >    layer data type of that body ( following the correct decoding of all 
> >    applicable transport layer Transfer-Encodings ) is determined via the 
> >    header fields Content-Type and Content-Encoding. These define a 
> >    two-layer, presentation level ordered encoding model:
> > 
> >       entity-body := Content-Encoding( Content-Type( data ) )

The HTTP protocol is primarily a presentation layer protocol that dabbles
in the transport layer itself. The 'entity body' of a message has always
meant "what actually came over the wire" and not "the result of all 
transport layer decodings". Same for all references to "messge body".
It has always meant  "whatever data showed up"... not "what it really is." 
That's a presentation layer thing and is still TBA even after the 'message'
arrives.

To say that either the Content-Type or Content-Encoding fields alone
( or taken together ) can ALWAYS tell you exactly what format the newly 
arrived entity body is ACTUALLY in is mis-leading. Those 2 fields don't change
even when multiple Transfer-Encodings have taken place and the actual
body data doesn't even resemble what those fields say it is.

'Content' specifically implies final presentation layer format of what 
actually
came over that wire, not the 'message body data' itself. The RFC's get
confused about that in general.

> Transfer-Encoding isn't included in the same framework in the RFC
> although that would work perfectly well. That's perhaps because MIME
> uses Content-Transfer-Encoding instead.

Exactly.... and people so often confuse the MIME layer with the HTTP
layer itself. MIME layer is a presentation thing... HTTP has transport
layers as well that are always 'in the ball game'.

Yours...
Kevin Kiley
CTO, Remote Communications, Inc.
http://www.RemoteCommunications.com
http://www.RemoteCommunications.com/rctpd/ - Free IETF encoding Server




Mime
View raw message