Re: HTTP as OCP transport, ICAP/2.02003-04-23 07:18:26Hilarie is correct in that the aim was to make it friendly to HTTP developers and apps with existing HTTP interfaces rather than strict HTTP compliance. If I recall correctly, the main reason that ICAP diverged from HTTP was that ICAP required chunking. Leaving chunking as optional made icap-enabled applications that dealt with the transfer of large amounts of data slow and inefficient. In particular virus scanning apps wanted a way to ack a small piece of data and tell the icap client to send more or not. Originally, ICAP was defined as an HTTP vectoring protocol or "HTTP over HTTP" - a way of encapsulating one complete HTTP message within another HTTP message. It still looks and smells a lot like HTTP. John At 02:25 23/04/2003, The Purple Streak, Hilarie Orman wrote: "Transport" in the classicial meaning is layer 4. However, it's possible for a protocol, like ICAP, to use a layer 5 protocol as its transport. That is, to fit entirely within the semantics of layer 5 and to introduce its own further semantics. I think that is the best way to view ICAP, from an architectural viewpoint. The deviations from HTTP semantics are trivial. The intent was to have something that ran on devices that already understood HTTP, so very little additional code would be writtent to support ICAP. Most multimedia streaming protocols run over HTTP fairly well. We've stated several times that the OPES processor and callout server have to be in the same administrative domain for security reasons. But, let's look at the case where they aren't, just for fun. Suppose someone put an HTTP intermediary in their path, as you suggest, and suppose it is an OPES process and it does HTTP content modification, wouldn't that be a mess? Even if the callout protocol is something else (SE), there might be an OPES box doing SE modification in the path. So, I'd think the callout protocol MUST carry a transport header with "no OPES" in order to control what could turn into an uncontrollable routing problem. Hilarie --------------------------------------------------------------- Please note new phone number: +1 347 613 2259 ---------------------------------------------------------------
|
|
||||||||||||||||