Martin,
I first responded to your message in detail (see below). While
responding I realized that we may be missing an important point that
Rob made. That realization prompted me to drastically simplify
encoding rules (see (***) at the end of the message below).
On Tue, 14 Oct 2003, Martin Stecher wrote:
Unless we find another good way to highlight this aspect in the
specs. Reminds me that we had parts of this discussion in early
June. I remember that we agreed that the OPES processor is
responsible for correct headers and that we can use the sizep
parameter to transmit a known content length.
Indeed! I believe decoupling processor actions when forming the final
message to the HTTP agent from OCP agent actions is the right thing to
do here. OCP scope is efficient exchange of application messages being
adapted. If a service wants to adapt transfer encodings it can, in
theory, do that. However, that would be a service-specific operation
built on _top_ of OCP mechanisms; not something we have to support
explicitly.
There we ended with two options I remember:
i) OPES processor MUST ignore Content-Length header
and depending on existence of sizep parameter
- adjust the Content-Length header
- introduce chunked transfer coding
- collect all data before sending on
- close the connection at the end
Agreed (some polishing of the above may be required).
We can now add: it MUST also ignore Transfer-Encoding header
because OCP message do not have transfer encodings
It can only ignore Transfer-Encoding if services are prohibited from
changing transfer encodings. This is actually related to recomputation
of Content-Length header above because Transfer-Encoding affects
Content-Length presence and value.
So, here is my today's proposal (sorry for changing my mind quickly
;-) I tries to combine your proposal with option i) above.
0) Do not negotiate Transfer-Encodings at all.
1) An OCP agent sending data MUST remove all
transfer encodings it supports. If any encodings remain, an
OCP agent sending data MUST specify remaining encodings
using the Transfer-Encoding parameter of a DUM
OCP message.
The above should be AMS message (not DUM), I think. Sorry. Encodings
have application message scope, not data chunk scope.
To increase interoperability, I would also add
An OCP processor SHOULD remove chunked encoding. Most
callout services are not expected to be able to dechunk.
A new transfer encoding MUST NOT be applied to a message.
This requirement is out of scope, I think. An agent can always argue
that the encoding was applied before the application message entered
OCP scope. We should always keep this scope picture in mind:
+--OCP agent--+ +--OCP agent--+
| | | |
things that | | things that
happen outside ----- OCP scope ---- happen outside
of OCP scope | | of OCP scope
| | | |
+-------------+ +-------------+
(processor side) (callout service side)
Do you see what I am getting at?
2) If an OCP agent receives Transfer-Encoding parameter
indicating unsupported encoding, it MAY terminate
the corresponding OCP transaction.
Agreed.
3) If the Content-Length is known by the callout service, a sizep
parameter MUST be added to all DUM messages.
An OPES processor MUST ignore Content-Length and Transfer-Encoding
HTTP headers.
I do not like the word "ignore". On a logical level, the processor
should delete Content-Length and Transfer-Encoding headers and either
add correct header(s) or do other things you list below.
XXX: Document the options it has:
- adjust the Content-Length header
- introduce chunked transfer coding
- collect all data before sending on
- close the connection at the end
(***) 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) 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.
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.
If an OCP agent receives transfer-encoded application data
in violation of the above requirement, the agent MAY terminate
the corresponding OCP transaction.
The new rules above also leave us an opportunity to document
transfer-encoding negotiations later if we decide they are worth
supporting.
You will need to add Content-Length and Transfer-Encoding
"recalculation" rules you mentioned above. As agreed, the processor is
still the enforcement point for those.
HTH,
Alex.