<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 27, 2016 at 7:57 PM, Alex Rousskov <span dir="ltr"><<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/27/2016 10:23 AM, Ozgur Batur wrote:<br>
<br>
> ICAP handles plain HTTP very well but it is not possible to<br>
> filter/change or even log content of websocket communication after<br>
> websocket upgrade over HTTP as far as I know. Is there any plan or<br>
> interest in developing some capability for Squid to control websocket<br>
> communication content?<br>
<br>
</span>There is interest but no specific plan or sponsor.<br>
<span class=""><br></span></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> There is no defined request/response protocol since websocket is<br>
> basically a socket but regexp matching in incoming and outgoing<br>
> content(json, xml,raw) with URL and client metadata info may have some<br>
> application like data leak prevention or achieving in corporate environment.<br>
<br>
</span>I am not sure regex would be a good idea in general, but passing<br>
tunneled traffic to eCAP/ICAP services is indeed useful in several<br>
environments, including WebSocket tunnels. The adaptation service will<br>
decide whether to use regex or something else to match raw data. Some<br>
existing services simply log (or relay/replay via TCP) received traffic<br>
without analyzing it so regex is just one of many possibilities here.<br>
<br>
FWIW, several things are needed to move forward, including:<br>
<br>
1. Adequate development time and skills (or sponsorship to pay for<br>
   them). The development of an essentially new adaptation vectoring<br>
   point is not a trivial project.<br>
<br></blockquote><div><br></div><div>I have involved in development of several ICAP services around Squid but have not had the chance to work on Squid code base directly. We may attempt implement a proof of concept with a few friends to better specify the task at hand current and learn about adaptation infrastructure of Squid.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. A specific proposal on how to map raw/tunnel data to HTTP messages<br>
   that eCAP and ICAP interfaces expect. The biggest difficulty here<br>
   may be mapping server-speaks-first protocols.<br></blockquote><div><br></div><div>I am not sure if it is possible to map websocket data to current adaptation services. Actually it may or may not be related but I am curious how Squid handles Comet(Ajax/HTTP Server Push) during ICAP processing. Maybe server data push can be mapped like Comet responses. About server first protocols, current ICAP services expecting encapsulated valid HTTP responses for requests will break of course. Maybe a mechanism like Allow 204 negotiation can be implemented between adaptation service and proxy. If adaptation service does not support server first pushes it can be bypassed. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. A project lead to organize/manage the project and guide the results<br>
   through the Squid Project review. This person could be the<br>
   primary developer and/or the specs writer, but does not have to be.<br>
<span class="HOEnZb"><font color="#888888"><br>
Alex.<br></font></span></blockquote></div><div class="gmail_extra"><br></div>Thanks,<br clear="all"><div><br></div>Ozgur
</div></div>