Subject: RE: transfer- and content-encoding

From: "Martin Stecher" <[email-masked]>
Date: Mon, 13 Oct 2003 14:39:55 +0200

Hi Rob,

thank you for your feedback - much appreciated.

> > I now wrote this paragraph.
> > 
> > 2.2.3 Transfer-Encodings
> > 
> >    The agents need to negotiate their encoding and decoding
> >    capabilities. Transfer encodings that are not supported 
> by one agents
> >    MUST NOT be used. HTTP messages with a transfer encoding 
> that is not
> >    supported by the callout server MUST be decoded by the 
> OPES processor
> >    and eventually be re-encoded with a supported transfer coding.
> > 
> >    Negotiation is done using the Transfer-Encoding parameter of the
> >    profile feature. Both agents advertise a list of supported
> >    transfer-codings for encoding and decoding. Encodings 
> listed earlier
> >    are preferred. The Transfer-Encodings parameter MAY be omitted if
> >    only the identity coding is supported.
> > 
> >    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. If an agent
> >    applies transfer encoding, it MUST NOT apply any 
> encoding more than
> >    once. The peer MAY reject content for which a transfer 
> encoding was
> >    applied more than once (XXX: document this as a potential exploit
> >    area).
> > 
> >    OCP agents supporting HTTP profiles SHOULD support and advertise
> >    identity and chunked transfer coding.
> > 
> >    		Transfer-Encodings  = "Transfer-Encodings:" SP
> >    		                      "(" [transfer-coding-list] ")"
> >    		transfer-coding-list = transfer-coding *("," 
> transfer-coding)
> > 
> >    		for example
> >    			Transfer-Encodings: (identity,chunked)
> > 
> >                                 Figure 5
> > 
> >    transfer-coding is defined in section 3.6 of [RFC2616].
> > 
> > 
> > 
> > What do you think?
> 
> Well the HTTP errata removed the 'identity' Transfer coding. 
> I don't see
> any reason to reinstate it.

Alex argued that an OPES processor might not be able or willing to
remove chunked transfer encoding. By forcing to name the identity
encoding, there is the possibility to not support it.
Questionable whether this is then what the OPES processor wants
because it requires (at least from the callout server) to send all
messages chunked encoded.

> Secondly, the prohibition against double
> encoding doesn't seem required to me: Chunked has explicit rules (*) -
> only one application, and always the last one. Other transfer codings
> may have their own rule. As a counter example, one may wish to use a
> transfer coding that provides delta-information, and use this 
> twice (say
> working of different basis objects).

That was the alternative we discussed. Just copying the chunked coding
requirements from RFC 2616. I am fine with that solution too.
Might really be the way how OCP adapts HTTP best.
Alex: What do you think?

Thank you
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 13 Oct 2003 23:02:44 -0600 (MDT)

On Mon, 13 Oct 2003, Martin Stecher wrote:

> That was the alternative we discussed. Just copying the chunked
> coding requirements from RFC 2616. I am fine with that solution too.
> Might really be the way how OCP adapts HTTP best. Alex: What do you
> think?

We probably need to do more or less than just copying HTTP rules.
Please see my response to Rob. I am undecided at this point,
unfortunately. I want to support more than identity, but it is seems
rather difficult. I hope the questions I raise will help us narrow
down the solution space.

Thanks,

Alex.