Hi,
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.
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?
Thank you
Martin