Re: [squid-dev] [PATCH] Add reply_header_add

2016-03-15 Thread Alex Rousskov
On 03/15/2016 07:29 PM, Nathan Hoad wrote: > On 15 March 2016 at 12:11, Alex Rousskov wrote: >> On 03/14/2016 05:46 PM, Nathan Hoad wrote: >> * You have not adjusted HTTP response headers produced by >> Http::One::Server::writeControlMsgAndCall(). Please either apply the >> same logic to those

[squid-dev] Build failed in Jenkins: trunk-full-matrix » clang,d-debian-unstable #126

2016-03-15 Thread noc
See -- [...truncated 6843 lines...] make[5]: Leaving directory

[squid-dev] Jenkins build is back to normal : trunk-full-matrix » clang,d-debian-jessie #126

2016-03-15 Thread noc
See ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [PATCH] Add reply_header_add

2016-03-15 Thread Nathan Hoad
On 15 March 2016 at 12:11, Alex Rousskov wrote: > On 03/14/2016 05:46 PM, Nathan Hoad wrote: > >> The attached patch implements reply_header_add, for adding HTTP >> headers to reply objects as they're sent to the client. > > Thank you for this useful addition.

Re: [squid-dev] [RFC][PATCH] Bug4438 second attempt: give MemBlob its own pools

2016-03-15 Thread Alex Rousskov
On 03/14/2016 02:11 PM, Kinkie wrote: > this second attempt at bug4438 tries a different approach: by giving > MemBlob its own pools and having a hard initialization dependency in > MemBlob's allocating function, instead of relying on memAllocString. Forgive me if I missed how this decision

Re: [squid-dev] [PATCH] assertion failed: Write.cc:41: "!ccb->active()"

2016-03-15 Thread Christos Tsantilas
On 03/15/2016 07:28 PM, Christos Tsantilas wrote: I applied the t4 patch to trunk as r14592 The t4 patch applied to squid-3.5 as r14001 I am attaching the t4 patch for squid-3.5. I believe that we should apply this patch for this major reasons: - The (statefull) FTP protocol requires

Re: [squid-dev] [PATCH] assertion failed: Write.cc:41: "!ccb->active()"

2016-03-15 Thread Christos Tsantilas
I applied the t4 patch to trunk as r14592 I am attaching the t4 patch for squid-3.5. I believe that we should apply this patch for this major reasons: - The (statefull) FTP protocol requires good coordination between client-side and server side. The pinned connections is one mechanism which

Re: [squid-dev] [PATCH] implement RFC3986

2016-03-15 Thread Alex Rousskov
On 03/15/2016 07:05 AM, Kinkie wrote: >> I do not think so. The crux of the issue is that you are defending a >> medium-size template function as a necessary and small evil, while I am >> attacking the principle or direction of accommodating helper needs by >> making Squid code worse. > > Hi, >

Re: [squid-dev] [PATCH] Better support for unknown URL schemes

2016-03-15 Thread Alex Rousskov
On 03/15/2016 09:36 AM, Amos Jeffries wrote: > Squid already contains AnyP::PROTO_UNKNOWN support for unknown protocols > but currently does not preserve the actual string value received for them. > > This adds a textual representation ('image') to the UriScheme object to > fill that gap and

[squid-dev] [PATCH] Better support for unknown URL schemes

2016-03-15 Thread Amos Jeffries
Squid already contains AnyP::PROTO_UNKNOWN support for unknown protocols but currently does not preserve the actual string value received for them. This adds a textual representation ('image') to the UriScheme object to fill that gap and ensure that all URL representatinos (ie cache keys, logs

Re: [squid-dev] [PATCH] implement RFC3986

2016-03-15 Thread Kinkie
> I do not think so. The crux of the issue is that you are defending a > medium-size template function as a necessary and small evil, while I am > attacking the principle or direction of accommodating helper needs by > making Squid code worse. Hi, the attached patch is a modification of what