Subject: AW: Summary of ICAP discussion

From: "Martin Stecher" <[email-masked]>
Date: Sat, 19 Oct 2002 00:34:24 +0200

Hi Markus,

> As Jeff mentioned in an earlier email, isn't an ICAP server 
> allowed by 
> the ICAP internet draft to reply to an ICAP client before the ICAP 
> server has received the entire encapsulated body? As such, 
> rather than 
> requesting a second preview, the ICAP server can request to send the 
> entire message, and than simply reply once it has received 
> enough data 
> to make an informed decision. Might even be the prefered way, 
> since it 
> might not be the case very often that the second and thrd preview ize 
> will be static and know a-priori? Or do you have a specific 
> scenario/application in mind?

That's right. It is very important that the ICAP server can start to send back data and that the client allows this and actively reads the data, otherwise its window size can go down to zero which can freeze the complete communication on that connection.
The procedure you subscribe is how it is done today if the ICAP server cannot answer with 204 after the preview.

But what I mean is an extension to that procedure.

Imagine that an ICAP server likes to be very sure that a claimed file type is really that file type. Let's say the ICAP server does not care about Quicktime movies and would like to answer with 204 for all those movies. But it has to be sure that the file is really a Quicktime movie.
The prefered preview size could be eight bytes and this will usually be enough to check the start of the file which typically shows the bytes 'moov' as the bytes 4-7 of the file. So usually right after the preview the ICAP server can answer with 204.
But in principle a Quicktime movie file could start with another atom and could have the 'moov' atom somewhere else. So the ICAP server gets eight bytes that could be a Quicktime movie but it is not sure.
Today the ICAP server will respond with 100 Continue and will now get the other 5 MB of the file transfered. Even if after another 100 bytes the ICAP server finds the moov atom and is not longer interested in the file it needs to receive and play back the complete file, wasting a lot of bandwidth.

So what I suggest is that a next protocol version offers the ability to return an additional value with the 100 Continue response specifying that the ICAP server likes to see an extended preview, maybe another 1KB and will then decide again whether to get the complete rest or to stop at that decision point with 204.

Martin

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 18 Oct 2002 20:57:55 -0400

Martin,

I'm completely with you, thanks for the clarification. What you 
describe is covered - in a more general case - in Section 3.1 of the 
OPES protocol requirements draft.

Thanks,
   Markus

Martin Stecher wrote:

> That's right. It is very important that the ICAP server can start to 
> send back data and that the client allows this and actively reads 
> the data, otherwise its window size can go down to zero which can 
> freeze the complete communication on that connection.
> The procedure you subscribe is how it is done today if the ICAP 
> server cannot answer with 204 after the preview.
>
> Imagine that an ICAP server likes to be very sure that a claimed 
> file type is really that file type. Let's say the ICAP server does 
> not care about Quicktime movies and would like to answer with 204 
> for all those movies. But it has to be sure that the file is really 
> a Quicktime movie.
> The prefered preview size could be eight bytes and this will usually 
> be enough to check the start of the file which typically shows the 
> bytes 'moov' as the bytes 4-7 of the file. So usually right after 
> the preview the ICAP server can answer with 204.
> But in principle a Quicktime movie file could start with another 
> atom and could have the 'moov' atom somewhere else. So the ICAP 
> server gets eight bytes that could be a Quicktime movie but it is 
> not sure.
> Today the ICAP server will respond with 100 Continue and will now 
> get the other 5 MB of the file transfered. Even if after another 100 
> bytes the ICAP server finds the moov atom and is not longer 
> interested in the file it needs to receive and play back the 
> complete file, wasting a lot of bandwidth.
>
> So what I suggest is that a next protocol version offers the ability 
> to return an additional value with the 100 Continue response 
> specifying that the ICAP server likes to see an extended preview, 
> maybe another 1KB and will then decide again whether to get the 
> complete rest or to stop at that decision point with 204.
>
> Martin
>