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