On Mon, 2003-10-13 at 20:23, Martin Stecher wrote:
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. 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).
As TE is hop by hop in HTTP, we need to ensure that any OPES processor's
TE field passed to upstreams, and TE field passed in responses to client
(for them to decide on upload Transfer-Encodings) is the processors
capabilities, not the actual client / origin respectively. Once we do
that, we know that an OPES processor will only receive codings it can
handle, so we can say MUST reject with a 5xx error (sorry to lazy to dig
up the best match) on an unhandlable transfer-coding. With that in
place, the interaction from processor to processor can 'trivially'
follow the HTTP Transfer-coding negotiation rules. That is, from a
protocol viewpoint, all transfer-codings must be removed and applied
anew across hops. By definition - implementations can shortcut this when
a compatible transfer-coding sequence exists across the relevant hop.
Cheers,
Rob
(*)
RFC 2616 3.6
" Whenever a transfer-coding is applied to a message-body, the set of
transfer-codings MUST include "chunked", unless the message is
terminated by closing the connection. When the "chunked" transfer-
coding is used, it MUST be the last transfer-coding applied to the
message-body. The "chunked" transfer-coding MUST NOT be applied more
than once to a message-body. These rules allow the recipient to
determine the transfer-length of the message (section 4.4)."
--
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.