Re: transfer- and content-encoding

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

On Fri, 10 Oct 2003, Martin Stecher wrote:

> I got some questions when I wanted to document negotiation on
> transfer-encoding and content-encoding. Both are planned to be named
> parameters in the feature structure of NO and NR messages.
>
> Example:
>
>    NO ({"38:http://iana.org/opes/ocp/HTTP/response";
>    Transfer-Encodings: (chunked)
>    Content-Encodings: (gzip, compress)
>    })
>    SG: 5;
>    NR {"38:http://iana.org/opes/ocp/HTTP/response";
>    Content-Encodings: (compress)
>    }
>    SG: 5;
>
> So, what does this mean?
>
> The OPES processor advertises its capability to handle chunked
> transfer encoding. So, it has the knowledge how to remove this
> encoding, i.e. how to preprocess the data for the callout server in
> order to transfer the data without transfer encoding (with identity
> encoding). Because transfer encoding is hop-by-hop, we can assume
> that an OPES processor can do this preprocessing for every
> transfer-encoding it supports; the data will not come in any
> transfer-encoding that is unknown to the OPES processor. This
> negotiation is also a hint for the callout server, because it MAY
> introduce a transfer encoding that is handled and advertised by the
> OPES processor but not anything else. That all seems to work.

Is the following summary accurate?

Transfer-Encoding list sent by OCP agent:
	Advertises encoding and decoding capabilities
	Accepts and generates only listed encodings
	Encodings listed earlier are preferred.
	Defaults to (identity)

Note that HTTP/1.1 default is (identity, chunked).

Also, how do we handle a situation where multiple transfer encodings
are applied?

> Content encodings are different. A proxy server usually does not
> need to have knowledge about the content encoding; it is an
> end-to-end encoding. Still the OPES processor can list those content
> encodings it is able to remove and the callout server lists those
> that it is aware of. But what does this really mean? If data is
> gzipped and callout server did not list that encoding, does this
> always mean that the processor should do the preprocessing; maybe
> the callout server does not need the decoded data at all and
> preprocessing is for nothing. And what about content encodings that
> both agents do not support? Simply still send the data to the
> callout server? And is the callout server allowed to introduce a
> content-encoding that the OPES processor does not support? At least
> after it has checked the request-header (where we also not know
> exactly which one it will get, an original or adapted version).
>
> Comments?
> Clarification?
>
>
> Let me suggest this interpretation:
>
> Content-Encoding list sent by OPES processor:
>     Does not advertise decoding capabilities
>     Does only accept adapted content in one of these encodings
>     No Content-Encoding parameter, if it does not care about new introduced encodings
>
> Content-Encoding list sent by callout server:
>     This is the list of supported content encodings.
>     If data is of any other encoding, OCP client shall do preprocessing if capabable, otherwise send the stuff as is.
>     If it accepts all content-encodings, or does not care, Content-Encoding parameter is omitted.
>
> Does that work?

I am not sure. The "if capabable, otherwise send the stuff as is" part
sounds fishy. It implies that we are declaring a weak preference
(please change encoding if possible) rather than negotiating an
interoperability requirement. That is, it sounds like the value of
Content-Encoding parameter cannot affect the result of the negotiation
(but might affect future processor actions).

I do agree that a typical OPES processor would not care about content
encodings or know how to change them (which is an _adaptation_ while
changing transfer encoding is not).

Also, the processor should not prohibit content-encoding adaptations.
If such a feature is needed, it should be implemented separately from
these negotiations because there may be other adaptations that an
OPES processor may want to prohibit.

How about this simpler version:

	A callout server MAY send a Content-Encodings list to
	indicate its preferences in content encodings. Encodings
	listed first are preferred to other encodings. An OPES
	processor MAY use any content encoding when sending
	application messages to a callout server.

	If an OCP agent receives an application message that it
	cannot handle due to specific content encoding, the usual
	transaction termination rules apply.


An alternative is to make early termination by processor
possible:

	A callout server MAY send a Content-Encodings list to
	indicate its requirements for supported content
	encodings. Encodings listed first are preferred to other
	encodings. A special "*" identifier stands for any
	encoding. Empty list indicates that the callout server is
	not capable of handling any content encodings and, hence,
	does not want to receive any content. Absent parameter
	defaults to ("*").

	An OPES processor MUST use a content encoding supported
	by the callout server or MUST terminate (or not initiate)
	the transaction that uses unsupported content encoding
	for application data.

	If an OCP agent receives an application message that it
        cannot handle due to specific content encoding, the usual
        transaction termination rules apply.

Which one will work better?

Also, how do we handle a situation where multiple content encodings are
applied?

Thanks,

Alex.