You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Sam Crawford <sa...@gmail.com> on 2011/03/22 10:53:38 UTC
HttpCore ICAP server
Morning,
I'm interested in developing an ICAP server for the purposes of
content filtering and rewriting. As per the RFC
(http://www.faqs.org/rfcs/rfc3507.html), ICAP uses an almost identical
request/response protocol to HTTP. The only discernible difference I
can see is it's use of different verbs (which HttpCore will take care
of already), a different URI scheme and a different protocol name
(ICAP/1.0 is the current one). For example, a typical request line
might be:
RESPMOD icap://icap.example.net/translate?mode=french ICAP/1.0
I've built a number of servers successfully with HttpCore NIO and am
very comfortable with its operation and performance. I'm wondering if
it's possible to re-use HttpCore for this project, even though it's
not HTTP.
So, a couple of questions:
1) Is this a sensible thing to do?
2) Is there an easy way to instruct HttpCore to accept ICAP messages
(like the request line above) and produce ICAP responses? Moreover, is
there a class I can extend to specify support for different protocols,
or does HttpCore not expose this?
Thanks,
Sam
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: HttpCore ICAP server
Posted by Sam Crawford <sa...@gmail.com>.
Oleg,
That's perfect, thank you. If this project moves forward I'll
contribute the ICAP protocol support in the same manner that the SIP
support was contributed.
Thanks,
Sam
On 22 March 2011 10:33, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Tue, 2011-03-22 at 09:53 +0000, Sam Crawford wrote:
>> Morning,
>>
>> I'm interested in developing an ICAP server for the purposes of
>> content filtering and rewriting. As per the RFC
>> (http://www.faqs.org/rfcs/rfc3507.html), ICAP uses an almost identical
>> request/response protocol to HTTP. The only discernible difference I
>> can see is it's use of different verbs (which HttpCore will take care
>> of already), a different URI scheme and a different protocol name
>> (ICAP/1.0 is the current one). For example, a typical request line
>> might be:
>>
>> RESPMOD icap://icap.example.net/translate?mode=french ICAP/1.0
>>
>> I've built a number of servers successfully with HttpCore NIO and am
>> very comfortable with its operation and performance. I'm wondering if
>> it's possible to re-use HttpCore for this project, even though it's
>> not HTTP.
>>
>> So, a couple of questions:
>>
>> 1) Is this a sensible thing to do?
>
> Seems so as long as ICAP employs the same mechanisms to delimit entity
> content as HTTP (content-length or chunk coding)
>
>> 2) Is there an easy way to instruct HttpCore to accept ICAP messages
>
> Easy? Probably not ;-) It is certainly doable, though. You would need a
> number of custom classes such ICAP specific message parser and formatter
>
>> (like the request line above) and produce ICAP responses? Moreover, is
>> there a class I can extend to specify support for different protocols,
>> or does HttpCore not expose this?
>>
>
> Have a look at the
>
> DefaultHttpRequestParser / DefaultHttpResponseWriter classes in the
> HttpCore NIO module. You would need similar classes that are ICAP
> protocol aware.
>
> Most probably you will need a custom HTTP connection implementation that
> employs ICAP specific message parser / formatter when serializing /
> deserializing messages. Otherwise you should be able to re-use existing
> HTTP protocol code.
>
> There is also an example of client side SIP protocol implementation
> based on HttpCore (blocking) in the contrib package you might want to
> take a look at:
>
> http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore-contrib/src/main/java/org/apache/http/contrib/sip/
>
> Hope this helps
>
> Cheers
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: HttpCore ICAP server
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2011-03-22 at 09:53 +0000, Sam Crawford wrote:
> Morning,
>
> I'm interested in developing an ICAP server for the purposes of
> content filtering and rewriting. As per the RFC
> (http://www.faqs.org/rfcs/rfc3507.html), ICAP uses an almost identical
> request/response protocol to HTTP. The only discernible difference I
> can see is it's use of different verbs (which HttpCore will take care
> of already), a different URI scheme and a different protocol name
> (ICAP/1.0 is the current one). For example, a typical request line
> might be:
>
> RESPMOD icap://icap.example.net/translate?mode=french ICAP/1.0
>
> I've built a number of servers successfully with HttpCore NIO and am
> very comfortable with its operation and performance. I'm wondering if
> it's possible to re-use HttpCore for this project, even though it's
> not HTTP.
>
> So, a couple of questions:
>
> 1) Is this a sensible thing to do?
Seems so as long as ICAP employs the same mechanisms to delimit entity
content as HTTP (content-length or chunk coding)
> 2) Is there an easy way to instruct HttpCore to accept ICAP messages
Easy? Probably not ;-) It is certainly doable, though. You would need a
number of custom classes such ICAP specific message parser and formatter
> (like the request line above) and produce ICAP responses? Moreover, is
> there a class I can extend to specify support for different protocols,
> or does HttpCore not expose this?
>
Have a look at the
DefaultHttpRequestParser / DefaultHttpResponseWriter classes in the
HttpCore NIO module. You would need similar classes that are ICAP
protocol aware.
Most probably you will need a custom HTTP connection implementation that
employs ICAP specific message parser / formatter when serializing /
deserializing messages. Otherwise you should be able to re-use existing
HTTP protocol code.
There is also an example of client side SIP protocol implementation
based on HttpCore (blocking) in the contrib package you might want to
take a look at:
http://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore-contrib/src/main/java/org/apache/http/contrib/sip/
Hope this helps
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org