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