[squid-users] Websocket content adaptation

[Ozgur Batur]

On Tue, Jun 28, 2016 at 4:48 PM, Alex Rousskov <
rousskov at measurement-factory.com> wrote:

> On 06/28/2016 06:43 AM, Ozgur Batur wrote:
> > On Mon, Jun 27, 2016 at 7:57 PM, Alex Rousskov wrote:
> >     FWIW, several things are needed to move forward, including:
> >
> >     1. Adequate development time and skills (or sponsorship to pay for
> >        them). The development of an essentially new adaptation vectoring
> >        point is not a trivial project.
>
>
> > 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.
>
> I recommend starting with the proposal described in my item #2. A proof
> of concept is usually needed when there is doubt that the concept can
> work in principle. There is no such doubt here IMO.
>

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 :)


>
> >     2. A specific proposal on how to map raw/tunnel data to HTTP messages
> >        that eCAP and ICAP interfaces expect. The biggest difficulty here
> >        may be mapping server-speaks-first protocols.
>
>
> > I am not sure if it is possible to map websocket data to current
> > adaptation services.
>
> It is possible to map virtually anything to HTTP messages and, hence, to
> eCAP/ICAP. For example, Squid maps FTP transactions to HTTP messages! A
> better mapping would preserve more information, make it easier to access
> that information by services that understand the protocol being mapped,
> have lower overhead, etc. However, it is clearly "possible" to come up
> with some mapping.
>
>
This is http://wiki.squid-cache.org/Features/FtpRelay feature right?
Previously Squid only supported FTP over HTTP, great improvement!


>
> > Actually it may or may not be related but I am
> > curious how Squid handles Comet(Ajax/HTTP Server Push) during ICAP
> > processing.
>
> Squid proxies regular HTTP/1 and FTP. That excludes pure server push
> until we add HTTP/2 support.
>
>
> > About server first protocols, current ICAP services expecting
> > encapsulated valid HTTP responses for requests will break of course.
>
> I do not think so. A proper mapping could present that spontaneous
> from-server message as an HTTP response to a trivial fake request
> (enough to identify the protocol and the server address).
>
> Needless to say, the WebSockets:HTTP mapping (and overall Squid
> functionality) can be improved if Squid understands WebSockets (as Amos
> has noted in his response), but I do not think such understanding is
> _required_ to accommodate many useful adaptation use cases.
>
>
> > 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.
>
> It is always possible to extend ICAP and eCAP, but, with all other
> factors being equal, extending should be a last-resort solution because
> most adaptation services will not support the extension and many of
> those services could work fine without that extension.
>
>
> HTH,
>
> Alex.
>
>
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.

Best Regards,

Ozgur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160628/93307496/attachment-0001.html>