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.
7. CONNECT method
A typical ICAP/1.0 client would generate a REQMOD request for
a CONNECT request but would not try a RESPMOD request
for the response or tunneled data.
The latter seems inconsistent. Should we document that both requests
and response are subject to adaptation but the tunnel is not?
I agree.
Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.