ietf-openproxy
[Top] [All Lists]

transfer- and content-encoding

2003-10-10 08:14:05

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



<Prev in Thread] Current Thread [Next in Thread>