Bhavian,
I never changed a request in that way but I think there is no reason why
it shouldn't work. It is allowed by the specs and an iCAP client
implementor should stand up now if there is a problem with this.
Section 4.1 just talks about "send back a modified version of the
request". Why listing up all possible kinds of modifications? Changing
the request method is just a sample.
Again the section 5.7.3 with the samples is a little misleading: It
first talks about a GET request that is changed and then remarks that in
the 2nd sample a POST request can be changed as well. By just reading
this, you could think that changing the method is not allowed but
section 4.1 is clear, I think.
Regarding the response modification: Replacing a successful download of
a file by an HTTP error message is a very normal operation that we are
doing a lot. It should work with all implementations (I hope).
Regards
Martin
-----Original Message-----
From: Bhavin Doshi [mailto:bdoshi(_at_)inktomi(_dot_)com]
Sent: Tuesday, June 12, 2001 12:26 AM
To: ietf-openproxy(_at_)imc(_dot_)org
Subject: iCAP Transformation Question
Hi,
I was going through iCAP protocol and had a question about section 4.1
[Request Modification].
When the request is sent to the ICAP server for transformation, can the
type of the request be transformed e.g. can a GET request be transformed
to a POST request. There is no clause which restricts the extent of
transformation. Is it possible to document that such a transformation
can or cannot occur and to which extent a request or a response can be
transformed.
One more scenario that I can think of is where a "HTTP/1.1 200 OK"
response be modified to be some error response like "HTTP/1.1 401
UNAUTHORIZED". Are these cases possible??
Thanx.
--Bhavin Doshi.