<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 28, 2016 at 4:48 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 06/28/2016 06:43 AM, Ozgur Batur wrote:<br>
<span class="">> On Mon, Jun 27, 2016 at 7:57 PM, Alex Rousskov wrote:<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>
<br>
> I have involved in development of several ICAP services around Squid but<br>
> have not had the chance to work on Squid code base directly. We may<br>
> attempt implement a proof of concept with a few friends to better<br>
> specify the task at hand current and learn about adaptation<br>
> infrastructure of Squid.<br>
<br>
</span>I recommend starting with the proposal described in my item #2. A proof<br>
of concept is usually needed when there is doubt that the concept can<br>
work in principle. There is no such doubt here IMO.<br></blockquote><div><br></div><div>That's great to hear that it is doable. But a solid proposal will require some preliminary work, at least if it comes from my side :) </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class=""><br>
<br>
>     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>
<br>
<br>
> I am not sure if it is possible to map websocket data to current<br>
> adaptation services.<br>
<br>
</span>It is possible to map virtually anything to HTTP messages and, hence, to<br>
eCAP/ICAP. For example, Squid maps FTP transactions to HTTP messages! A<br>
better mapping would preserve more information, make it easier to access<br>
that information by services that understand the protocol being mapped,<br>
have lower overhead, etc. However, it is clearly "possible" to come up<br>
with some mapping.<br>
<span class=""><br></span></blockquote><div><br></div><div>This is <a href="http://wiki.squid-cache.org/Features/FtpRelay">http://wiki.squid-cache.org/Features/FtpRelay</a> feature right? Previously Squid only supported FTP over HTTP, great improvement! </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">
<br>
> Actually it may or may not be related but I am<br>
> curious how Squid handles Comet(Ajax/HTTP Server Push) during ICAP<br>
> processing.<br>
<br>
</span>Squid proxies regular HTTP/1 and FTP. That excludes pure server push<br>
until we add HTTP/2 support.<br>
<span class=""><br>
<br>
> About server first protocols, current ICAP services expecting<br>
> encapsulated valid HTTP responses for requests will break of course.<br>
<br>
</span>I do not think so. A proper mapping could present that spontaneous<br>
from-server message as an HTTP response to a trivial fake request<br>
(enough to identify the protocol and the server address).<br>
<br>
Needless to say, the WebSockets:HTTP mapping (and overall Squid<br>
functionality) can be improved if Squid understands WebSockets (as Amos<br>
has noted in his response), but I do not think such understanding is<br>
_required_ to accommodate many useful adaptation use cases.<br>
<span class=""><br>
<br>
> Maybe a mechanism like Allow 204 negotiation can be implemented between<br>
> adaptation service and proxy. If adaptation service does not support<br>
> server first pushes it can be bypassed.<br>
<br>
</span>It is always possible to extend ICAP and eCAP, but, with all other<br>
factors being equal, extending should be a last-resort solution because<br>
most adaptation services will not support the extension and many of<br>
those services could work fine without that extension.<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
<br>
</blockquote></div><br>Thank you very much Alex, Amos. I will discuss this issue with other interested people, maybe I can find some resources. Also I need to do some homework.
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Best Regards,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ozgur</div></div>