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:
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