ietf-openproxy
[Top] [All Lists]

AW: Summary of ICAP discussion

2002-10-18 15:36:39

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

<Prev in Thread] Current Thread [Next in Thread>