On Tue, Jun 28, 2016 at 4:48 PM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> 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
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
