On 3/8/13 9:08 PM, Anil J wrote:
Just realized that earlier reply just addressed to Leif. Addressing it to
mailing list.
On Fri, Mar 8, 2013 at 8:36 PM, Leif Hedstrom <[email protected]
<mailto:[email protected]>> wrote:
On 3/8/13 6:28 PM, Brian Geffon wrote:
I do not think this is a good idea, if you're really looking to
write code in Java I would suggest maybe using Netty and writing a
simple proxy that way as opposed to using trafficserver.
Alternatively, you could take advantage of remapping to just
rewrite the url to a special endpoint that will fetch the original
content and return a modified response to trafficserver.
This is what people use the ICAP protocol for:
http://www.ietf.org/rfc/rfc3507.txt
Are you suggesting to use ICAP interface instead of libCurl/HTTP, in the
module? Or the having a module in the HTTP path, which goes outside for
processing itself is not good idea? I still not clear about Brian's
opinion why not to use trafficserver.
I'm saying, if you are going down the route of having "external" helper
applications to do content adaption, you should consider the ICAP protocol.
In my use case, I just want to leverage the third party application
servers (e.g. transcoders) to adjust the media content to suite the end
user client's requirement.
Nod, that's exactly what ICAP does. Now, if you third party applications
talks HTTP, you can just do what was suggested, and proxy requests through
them. I did a little thing for Yahoo a while back, called HIPES, which made
it easy to "pipeline" such application servers. Bryan, can you open source
HIPES? :)
-- Leif
