On Wed, 2003-10-15 at 01:35, Alex Rousskov wrote:
(***) However, I think Rob has a very good point that we are missing
here. Since HTTP transfer encodings are negotiated hop-by-hop by HTTP
agents, the OPES processor or the HTTP proxy that embeds it _have to_
support encodings they receive (or it becomes an HTTP problem)! For
example, an HTTP/1.0 proxy should not receive chunked encoding (by
default)
should never actually - it's a MUST NOT in rfc 2616.
because it will not be able to find the end of a chunked HTTP
message. Thus, I am thinking it would be acceptable to simplify the
above rules:
Adaptations that use HTTP transfer-encodings MUST be
explicitly negotiated. This specification does not document
such negotiations.
Yes.
In the absence of explicit transfer-encoding negotiations, an
OCP agent MUST NOT send transfer-encoded application messages.
Informally, this means that the agent or its environment have
to make sure that all transfer encodings are stripped before
an application message enters OCP scope.
Yes.
If an OCP agent receives transfer-encoded application data
in violation of the above requirement, the agent MAY terminate
the corresponding OCP transaction.
I prefer MUST terminate. It will make things cleaner - there is little
benefit in having an undefined behaviour, when we have explicit
requirement for negotiation already there (three paragraphs up :}).
Cheers,
Rob
--
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.