Quick update: The problem isn't with Squid. When MWG decides it wants to send an early response, it seems it also decides to send garbage data after a few KB of valid data. Squid notices that MWG is trying to send a chunk bigger than advertised and promptly closes the connection. On Wed, May 18, 2016 at 6:46 PM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > On 05/18/2016 03:56 PM, Rob Worsnop wrote: > >> In certain circumstances, MWG will start streaming the RESPMOD response >> before Squid has finished sending all the chunks in the RESPMOD request. >> >> Squid does not like this. > > If Squid does not like this, it is a Squid bug IMO. > > >> As far as I can tell, ICAP is no different from HTTP > > In both protocols, a server may start sending the response before the > entire request has been received, and a robust client implementation > ought to accept such "early" responses even if the protocol does not > explicitly require their support. An early response has to comply with > all the other protocol rules, of course, but there are cases where such > compliance is not a problem. > > In HTTP, early responses are usually errors because the server is > unlikely to know that the request will be successful until seeing the > end of the request. > > In ICAP, early responses are much more useful (and common) because an > ICAP server can "pipeline" the HTTP message back to the ICAP client, > drastically reducing message buffering requirements and user delays. > IIRC, Squid used to support early responses well. > > > HTH, > > Alex. > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
