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.