On Sat, 18 Oct 2003, Martin Stecher wrote:
An OCP Agent that knows the exact length of the HTTP
message entity (Section 7.2.2 Entity Length in RFC 2616),
SHOULD announce that length using an AM-EL named parameter
of an AMS message.
May I quote you here, Alex? ;-)
You wrote on June, 2nd:
"Why not a MUST? If something so important is known, why not report it?"
:-) Answering my own question here, apparently: if NOT doing the
required action does not lead to interoperability problems, it is a
SHOULD, not a MUST. But this is all very fuzzy, of course. If you
prefer a MUST, I would not argue (for a few months, anyway).
What I am missing in this description is the mention of the adapted
message part. As you already pointed out earlier, we have to make it
very clear what length we are talking about. If, for example, an
OPES processor is sending a HTTP message for response modification
with request-body as optional part and skipping the response- body
part, the AM-EL parameter must still specify the size of the
response body length and not of the request body length.
How about this:
An OCP Agent that knows the exact length of the HTTP
message entity (Section 7.2.2 Entity Length in RFC 2616)
at the time it sends the AMS message, MUST announce that
length using an AM-EL named parameter of an AMS message.
In the HTTP request profile AM-EL is the length of the
request-body part and in the HTTP response profile the
length of the response-body part each before any
transfer-codings have been applied.
I agree that we have to be specific. Your version is fine. It might be
better to document "entity" when we document "profiles" instead of
piggibacking entity definition to this requirement, but this is up to
you.
an OPES processor would
have to use chunked transfer-encoding or terminate
the HTTP connection after sending the adapted HTTP message
to the next HTTP hop.
This is not always true. OPES processor could wait for the
transaction to complete (on cost of latency) or close the
connection. It's a little tricky and their is no general advice. I
tried to discuss this is the draft in the section Message Header
Correctness, subsection about Message Length. It's not yet perfect
and needs polishing but I think it is better to have a separate
section about this.
Agreed.
I think the specs should presume that most implementations are sending
correct AM-ELs. Therefore I vote for SHOULD.
Agreed.
Again, I would prefer to keep this short in the (new) section that
will introduce AM-EL and have the detailed description in the
message length section.
Agreed.
Alex.