On Fri, 10 Oct 2003, Martin Stecher wrote:
If data is encoding with transfer encoding X and then again with
encoding Y, then this must happen.
If the other agent advertises both X and Y, then data can be sent with
double encoding.
If the other agent advertises only X, then message needs to be Y-decoded,
staying X-encoded.
If the other agent advertises only Y, then message needs to be decoded
completly, re-encoding to Y is possible.
If the other agent advertises neither X not Y, then message needs to be
decoded completly.
In other words:
An OCP agent MUST send data using only transport
encoding(s) supported by its peer, regardless of the number of
transport encodings applied to the application message. To
satisfy previous requirement, the agent may have to
partially or fully decode the application message and
then re-encode it as necessary.
An OCP agent receiving application data from its peer, MUST
be ready to accept multiple transport encodings, in any order,
if it advertised support for multiple transport encodings.
Do we need to prohibit encoding sequences like
(chunked,identity,chunked,identity)? The above rules do not.
Regarding content encoding:
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.
Fine with me. It also means that the OPES processor does not use
the Content-Encodings header at all.
Right.
We just still need to allow that the callout service still handles
the data (for example replacing by an error message or returning unchanged)
even if it does not support that encoding, rather than termination the
transaction.
I think that is implied by the above rules, but we can be more
specific:
The list of preferred content encodings does not
imply lack of support for other encodings. OPES
processor MUST NOT bypass a service just because
the actual content encoding does not match service's
preferences.
Also, how do we handle a situation where multiple content
encodings are applied?
Not an issue when following your first option. Or is there one that
I do not see?
Not an issue when following the first option.
Thank you,
Alex.