<div dir="ltr">Thank you very much for explanation Amos.<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 28, 2016 at 4:52 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 29/06/2016 12:43 a.m., Ozgur Batur wrote:<br>
<span class="">> On Mon, Jun 27, 2016 at 7:57 PM, Alex Rousskov wrote:<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 adaptation<br>
> services. Actually it may or may not be related but I am curious how Squid<br>
> handles Comet(Ajax/HTTP Server Push) during ICAP processing.<br>
<br>
</span>Last time I looked at those they were just using regular HTTP<br>
long-pollinng techniques. Though some may have moved to WebSockets or<br>
HTTP/2 now.<br>
<br>
Squid does not have to do anything for those. The clients and server<br>
involved do the mapping of their data into various HTTP requests and<br>
replies. So as far as Squid is concerned they are just regular long<br>
duration GET or POST requests. Which since they are HTTP messages can be<br>
passed to the ICAP service in the normal ways.<br>
<div class="HOEnZb"><div class="h5"><br>
Amos<br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</div></div></blockquote></div><br><div><br></div>
</div></div>