On Fri, 21 Nov 2003, Robert Collins wrote:
On Fri, 2003-11-21 at 08:59, Alex Rousskov wrote:
6. 100 Continue
I agree that multipe origin am-ids would solve this issue best
but it seems to be the wrong timing to me to change the concept
now and allow them.
So, for now, should we say that 100 Continue MUST NOT be forwarded to
callout servers unless their adaptation is negotiated? (and thanks for
the ICAP info).
Huh? This seems orthogonal: the handshaking involved in rfc 2616
uploads is essentially a buffering mechanism, the adaptation device
must handle the client and server ends as per HTTP semantics. So
far, the callout protocols have no 'send / don't send' concepts in
them, so the semantics there are clear. The corollary is that 100
continue must (not MUST) be sent http/1.1 clients without delay, and
the adaptation device implement buffering before sending to the http
origin / delaying of reads from the client as appropriate for local
policy.
Robert,
I am sorry but I do not understand what you mean. Can you
rephrase please? We are trying to decide what to do when the origin
server responds with 100 Continue before sending 200 OK; there is no
mechanism in current OCP Core to handle multiple original application
messages for the same transaction.
Are you saying that 100 Continue mechanism is essentially
external to HTTP messages being adapted? Like, for example, HTTP
connections or TCP ACKs are external to the messages that flow on
those connections -- we adapt messages and not the connections or
ACKs. If so, the suggested "MUST NOT forward" rule seems appropriate.
Or are you saying that 100 Continue messages must be forwarded
to the callout server for some reason?
Please clarify.
Thank you,
Alex.