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. > 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. > 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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
