Hi Arumugam,
2. One concern over the request modification.
Icap client sends the client request to icap server. The
icap server
could sent an adapted request , an HTTP error message
indicating the client request is prohibited or ICAP error msg.
The icap server sends ICAP error msg due to an error in ICAP
semantics such as ICAP request is not correct or service not
available.
In this case , the icap client can either forward the original
request without any modification to OS or send an error msg to
client stating that the service could not be provided.
It would be useful if the draft says how to handle this scenario.
There is no clear way how to handle this.
Examples:
- If a virus filtering RESPMOD service sends an ICAP error, the original
request is probably better not bypassed
- If an advertising removal RESPMOD service sends an ICAP error, bypassing the
original response is probably the prefered option.
- If an Internet Access Management REQMOD service sends an ICAP error, there
will be companies that would allow a bypass while others prefer to block the
request.
So usually the bypass flag is an option to set with the ICAP service that is
defined at the ICAP client. It does not belong to the protocol specs, I think.
3. The draft is not posing any prerequisite to the tools used
to provide
the actual services. Based on the protocol , it seems to
be valid to
have few prerequisite on the service tools.
1. The tool has to be run in non-interactive mode. GUI interface is
not needed.
2. The tool should be started by cli. Allows to pass command line
arguments.
3. In the simplest form, each instance of the tool serves only one
request.Considering the overhead due to the size of the
tool and
time to load and make it ready , it would be fine to
make a single
instance of the tool to serve multiple requests either
sequentially or parallely. I am not sure how far this is
achievable.
Does this belong to the protocol specs?
4. It could be possible to make use of the ICAP protocol for real
bandwidth savings.This is possible by providing a service
called decompression.
For example, consider a scenario.
The client makes a request to html page in OS. Due to ICAP
,a request
with a url which points to the compressed copy of the html page is
sent to OS. This is done in REQMOD mode.
OS sends back the compressed data. The compressed data is sent to
ICAP server which can decompress and send the data in the format
requested by the end-user. This is done in RESPMOD mode.
Thus the bandwidth needed to transfer the html page is
reduced to the
level of compression.
If this service is considered as a valid one, then this
service could
be mentioned in the draft.
While having good examples in a draft is nice for easier understanding, it is
impossible to provide the full list of all valid and usefull services.
I think a place like the ICAP forum is better to collect all ideas for ICAP
services.
Regards
Martin