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

On 02/13/2016 01:47 AM, Amos Jeffries wrote: > On 11/02/2016 5:27 a.m., Alex Rousskov wrote: >> On 02/10/2016 08:59 AM, Amos Jeffries wrote: >>> This is the updated patch implementing RFC 3986 URI coding ('URL-escaping'). >>> >>> So far all the audit suggesti

Re: [squid-dev] [PATCH] shuffle SessionCacheRunner to libsecurity

On 02/12/2016 08:30 AM, Amos Jeffries wrote: > On 12/02/2016 4:48 p.m., Alex Rousskov wrote: >> On 02/11/2016 08:14 PM, Amos Jeffries wrote: >>> On 12/02/2016 7:21 a.m., Alex Rousskov wrote: >>>> On 02/11/2016 10:20 AM, Amos Jeffries wrote: >>>

Re: [squid-dev] Patches proposal

On 02/17/2016 10:29 AM, Amos Jeffries wrote: > On 18/02/2016 5:59 a.m., William Lima wrote: >>> the other uses Redis for certificate caches. >> A polished version of this would be a very welcomed addition for busy >> bumping proxies IMO! >> >> AFAICT, this polishing would require generalizing

Re: [squid-dev] [PATCH] Bug 4111 fix

On 02/16/2016 05:05 PM, Amos Jeffries wrote: > This bug had unfortunately gotten lost in the flood. The bug reporters > proposed patch seems to be correct in terms of its intention. > > This version of the patch adds the missing {} and uses fatalf() instead > of exit(). It also goes a little

Re: [squid-dev] Squid: Small packets and low performance between squid and icap

On 02/16/2016 05:55 PM, Prashanth Prabhu wrote: >> * A call to c_str() should not increase SBuf::len_ either because it >> does not add a new character to the SBuf object. That call just >> terminates the underlying buffer. > > Well, without an increment of the MemBlob::size_ (or with an

Re: [squid-dev] Patches proposal

On 02/17/2016 11:27 AM, Amos Jeffries wrote: > On 18/02/2016 6:43 a.m., Alex Rousskov wrote: >> On 02/17/2016 10:29 AM, Amos Jeffries wrote: >>> FYI: the model we have for helpers is that each backend type is >>> represented by a different helper binary that end-use

Re: [squid-dev] Patches proposal

On 02/18/2016 05:48 AM, Eliezer Croitoru wrote: > However I do see one specific issue with a DISK and Redis DB. > If for any reason the site headers will contain HSTS rules and the Redis > DB(mem only..) will be restarted then the certificate would be different > and the client will probably(to

[squid-dev] Trunk profusely leaks memory

Hello, I accidentally noticed that recent trunk code does not appear to free various request-related structures (at least). Here are partial valgrind results after just ~300 benign requests: > ==8921==definitely lost: 1,794,688 bytes in 4,058 blocks > ==8921== 1,193,168 (1,067,712

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

On 02/20/2016 11:27 AM, Kinkie wrote: > Sorry to bring this topic up again, but honestly I don't understand > your position. > > I believe that the deadlock we currently are in There is no deadlock. I think the design decision to use templated escape functions to accomodate std::string-using

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

On 03/10/2016 12:14 PM, Christos Tsantilas wrote: > I am attaching two patches for this bug. I will re-summarize the problem we are dealing with using higher-level concepts so that it is easier to grok what Christos is talking about: 1. Ftp::Client cannot deal with more than one FTP command

Re: [squid-dev] [PATCH] shared_memory_locking

On 03/10/2016 01:33 AM, Amos Jeffries wrote: > On 10/03/2016 11:14 a.m., Alex Rousskov wrote: >> Hello, >> >> The attached patch adds a "shared_memory_locking" configuration >> directive to control mlock(2). >> >> Locking shared memory at star

[squid-dev] [PATCH] Bug 7: Headers are not updated on disk after 304s

Hello, The attached compressed patch fixes a 15+ years old Bug #7 [1] for the shared memory cache and rock cache_dirs. I am not aware of anybody working on ufs-based cache_dirs, but this patch provides a Store API and a cache_dir example on how to fix those as well. [1]

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

On 03/13/2016 01:57 PM, Christos Tsantilas wrote: > On 03/10/2016 11:35 PM, Alex Rousskov wrote: >> On 03/10/2016 12:14 PM, Christos Tsantilas wrote: >>> if (master->serverState == fssHandleDataRequest) { >>> +

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

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()"

On 03/13/2016 10:17 PM, Amos Jeffries wrote: > On 14/03/2016 8:57 a.m., Christos Tsantilas wrote: >> On 03/10/2016 11:35 PM, Alex Rousskov wrote: >>> The above logic looks correct to me, but I feel like I am reading an >>> inside-out code. Please consider this instead

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

On 03/13/2016 10:17 PM, Amos Jeffries wrote: > * stopOriginWait() does not make sense in English. Not my expertise area, but it does make sense to me. "Wait" can be a noun as in "we had a long wait" (as suggested by Google). Would you prefer stopOriginWaiting() accompanied by

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

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

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

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] assertion failed: Write.cc:41: "!ccb->active()"

On 03/14/2016 02:58 PM, Christos Tsantilas wrote: > On 03/14/2016 06:33 PM, Alex Rousskov wrote: >> The only remaining doubt in my mind is the combination of delayedReply >> and fssHandleDataRequest state. The above code appears to assume that, >> in fssHandleDataRequest, d

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

On 03/10/2016 02:35 PM, Alex Rousskov wrote: > Amos, do you want us to port take2 to v3.5? The take1 patch for v3.5 is > enough to fix the known assertion. Take2 fixes that assertion as well, > but it is bigger because it also fixes design problems that may lead to > other bugs in v3.

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

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. Unfortunately, it needs quite a bit of work. * Please _carefully_ review your

[squid-dev] [PATCH] shared_memory_locking

Hello, The attached patch adds a "shared_memory_locking" configuration directive to control mlock(2). Locking shared memory at startup avoids SIGBUS crashes when kernel runs out of RAM during runtime. This has been discussed during the "[RFC] Fix shared memory initialization, cleanup. Ensure

[squid-dev] [PATCH] g++ -Woverloaded-virtual

Hello, I accidentally discovered that Squid does not use -Woverloaded-virtual when compiled with GCC. I found that warning useful in other projects. Enabling it for Squid exposes one bug-in-the-making: It looks like an 3rd Ftp::Relay::failed() argument was forgotten. The attached patch

Re: [squid-dev] [PATCH] Bug 7: Headers are not updated on disk after 304s

On 03/11/2016 02:17 AM, Amos Jeffries wrote: > On 11/03/2016 2:59 p.m., Alex Rousskov wrote: >> The attached compressed patch fixes a 15+ years old Bug #7 [1] for >> the shared memory cache and rock cache_dirs. I am not aware of anybody >> working on ufs-based cache

Re: [squid-dev] [PATCH] risky_server_pconn_reuse option

On 03/08/2016 05:38 AM, Amos Jeffries wrote: > On 9/03/2016 1:30 a.m., Eduard Bagdasaryan wrote: >> Followed your suggestions in [t4] patch. > +1. Committed to trunk (r14589). Thank you, Alex. ___ squid-dev mailing list

Re: [squid-dev] [PATCH] g++ -Woverloaded-virtual

On 03/12/2016 08:10 PM, Amos Jeffries wrote: > On 12/03/2016 7:41 p.m., Alex Rousskov wrote: >> Disclaimer: The Ftp::Relay::failed() fix is correct from removing the >> warning point of view, but I have not checked whether the patched code >> handles non-nil ftpErr correctly

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

On 03/16/2016 11:33 AM, Kinkie wrote: >>> Will it be initialized at all? I'd expect that fromHexTable, which is >>> const and POD be simply laid out in the data segment and not require >>> initialization at all. >> >> Are you implying that >> >> (a) fromHexTable is a C++11 constexpr _and_ >> (b)

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

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 &

Re: [squid-dev] [PATCH] shared_memory_locking

On 03/10/2016 08:32 PM, Eliezer Croitoru wrote: > Can this be verified in any way? Verify that I am not imagining things? Sure! If looking at fatal() itself is not enough to realize that it does not log the FATAL message until _after_ calling a few "heavy" functions (which may fail on their

Re: [squid-dev] [PATCH] shared_memory_locking

On 03/10/2016 08:28 PM, Amos Jeffries wrote: >>> * fatalf() sends a FATAL level error to cache.log. No need to preceed it >>> with a less important debugs ERROR message saying the same thing. >> There is such a need, unfortunately: The FATAL error is printed much >> later than the error is

Re: [squid-dev] [PATCH] Bug 4438 - string pool refactoring

On 03/30/2016 11:15 AM, Amos Jeffries wrote: > On 30/03/2016 8:19 a.m., Alex Rousskov wrote: >> This committed code does nothing useful: Static variables, such as >> "pools" are zero-initialized by default and that happens at constant >> initialization time.

[squid-dev] [PATCH] Do not hide important/critical messages

Hello, While working on Squid bug 4465 (Header forgery detection leads to crash), I noticed that Squid may hide important/critical debugs() messages from the admin if those messages are assembled using code that also uses debugs(). For example, unpatched Squid console only says: 2016/03/27

Re: [squid-dev] [PATCH] Remove ServerOptions "partial copy" copy constructor

On 04/07/2016 03:22 AM, Amos Jeffries wrote: > On 7/04/2016 6:10 p.m., Alex Rousskov wrote: >> The attached patch removes broken and, AFAICT, unused "partial copy" >> ServerOptions copy constructor. > A (full) copy-constructor is needed on some systems for the cle

[squid-dev] [PATCH] Remove ServerOptions "partial copy" copy constructor

Hello, The attached patch removes broken and, AFAICT, unused "partial copy" ServerOptions copy constructor. I am not intimate with the affected code, so more work may be needed around this change: If the partial copy constructor was meant to be abused for something, then a new approach

[squid-dev] [PATCH] Replace new/delete operators using modern C++ rules

Hello, This change was motivated by "Mismatched free()/delete/delete[]" errors reported by valgrind and mused about in Squid source code. I speculate that the old new/delete replacement code was the result of slow accumulation of working hacks to accomodate various environments, as compiler

[squid-dev] [PATCH] Avoid startup/shutdown crashes

Hello, We spent the last few days chasing down trunk startup crashes. Backtraces pointed to the OpenSSL context management bugs, but the actual problem was related to the global destruction disorder in the SBuf statistics code. The attached patch preamble contains the proposed commit message

Re: [squid-dev] [PATCH] Do not hide important/critical messages

On 04/09/2016 10:42 PM, Amos Jeffries wrote: > On 29/03/2016 12:44 p.m., Alex Rousskov wrote: >> unpatched Squid console only says: >> >> 2016/03/27 14:19:48.297| SECURITY ALERT: By user agent: >> 2016/03/27 14:19:48.297| SECURITY ALERT: on URL: dut70.test:443 >

Re: [squid-dev] [PATCH] Avoid startup/shutdown crashes

On 04/09/2016 10:16 PM, Amos Jeffries wrote: > On 7/04/2016 6:04 p.m., Alex Rousskov wrote: >> Hello, >> >> We spent the last few days chasing down trunk startup crashes. >> Backtraces pointed to the OpenSSL context management bugs, but the >> actual

Re: [squid-dev] [PATCH] Replace new/delete operators using modern C++ rules

On 04/09/2016 10:50 PM, Amos Jeffries wrote: > In principle this is a great step forward, but I would like confirmation > about the portability side of things before it actually gets merged. Me too. However, please keep in mind that beyond [unlikely] compilation failures, it would be difficult

Re: [squid-dev] [PATCH] Remove ServerOptions "partial copy" copy constructor

On 04/09/2016 11:03 PM, Amos Jeffries wrote: > On 8/04/2016 2:57 a.m., Alex Rousskov wrote: >> On 04/07/2016 03:22 AM, Amos Jeffries wrote: >>> On 7/04/2016 6:10 p.m., Alex Rousskov wrote: >>>> The attached patch removes broken and, AFAICT, unused "pa

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

u know whether ACLs are required for HeaderWithAclList (i.e., our "ACLs may be specified" wording is misleading) or optional (i.e., our "Usage: ... field-value acl1 [acl2]" is wrong)? Thank you, Alex. > On 16 March 2016 at 14:15, Alex Rousskov > <rouss...@measurement-fac

Re: [squid-dev] [PATCH] shared_memory_locking

On 03/10/2016 10:04 PM, Amos Jeffries wrote: > Okay fine with me now. > > +1. Please apply :=) Committed as trunk r14603 after fixing the lock() method description copy-paste error. Alex. ___ squid-dev mailing list squid-dev@lists.squid-cache.org

Re: [squid-dev] [PATCH] Bug 4438 - string pool refactoring

On 03/25/2016 07:08 AM, Amos Jeffries wrote: > This was audited off-list, and a slightly more polished version applied > to trunk as rev.14604 I have not seen the off-list audit, but the committed version is buggy IMHO: > MemPools & > MemPools::GetInstance() > { > /* Must use this

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

On 03/16/2016 02:04 AM, Kinkie wrote: > On Tue, Mar 15, 2016 at 9:43 PM, Alex Rousskov wrote: >> 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

Re: [squid-dev] [PATCH] tentative fix for bug 4438

On 03/05/2016 04:31 AM, Kinkie wrote: > ensuring that mempools are initialized before MemBlob is > used. Please explain how * a call to Mem::Init() at some random time during dynamic initialization[1] would _ensure_ that Mem::Init() is called before * MemBlob is used. I see no dependency

Re: [squid-dev] [PATCH] tentative fix for bug 4438

On 03/06/2016 11:16 AM, Kinkie wrote: > As I cannot reproduce the issue it's really hard to do a root cause analysis. Agreed. However, if you can make SBuf/MemBlob use memory pools before those pools are initialized, then we do have a bug worth fixing (even if Yuri does not suffer from that

Re: [squid-dev] [PATCH] tentative fix for bug 4438

On 03/06/2016 02:15 PM, Kinkie wrote: > On Sun, Mar 6, 2016 at 9:41 PM, Alex Rousskov wrote: >> On 03/06/2016 11:16 AM, Kinkie wrote: > Having the MemBlob pools be static > members of the MemBlob class will guarantee proper initialization > before even the first MemBlob is i

Re: [squid-dev] [PATCH] Bug 4430 Squid crashes on shutdown while cleaning up idle ICAP connections.

On 03/02/2016 02:15 AM, Christos Tsantilas wrote: > On 03/01/2016 04:36 AM, Amos Jeffries wrote: >> Okay. +1 on that 3.5 patch going in. > I applied the patch to squid-3.5 branch as r14000. > Probably we should apply it to trunk too, as a temporary solution I agree, especially if you do not

Re: [squid-dev] [PATCH] Increase request buffer size to 64kb

On 03/31/2016 11:22 PM, Nathan Hoad wrote: > I've attached two patches - they're functionally identical, one uses > SBuf and the other using MemBuf. I am only looking at SBuf patch because MemBuf is deprecated. I have not read your analysis email yet, but will do so soon. Meanwhile, I wanted to

Re: [squid-dev] [PATCH] Increase request buffer size to 64kb

On 03/30/2016 11:50 PM, Nathan Hoad wrote: > Alex, I've tried 8, 16, 32, 128 and 512 KB values - all sizes leading > up to 64 KB scaled appropriately. 128 and 512 were the same or > slightly worse than 64, so I think 64 KB is the "best value". Sounds good, but it is even more important that you

Re: [squid-dev] [PATCH] Increase request buffer size to 64kb

On 03/30/2016 04:29 AM, Amos Jeffries wrote: > The network HTTP request buffer is controlled by request_header_max_size > - default 64KB. You may be thinking about client_request_buffer_max_size (512 KB) instead: request_HEADER_max_size controls HTTP request header parsing, not request buffering

Re: [squid-dev] [PATCH] Bug 4438 - string pool refactoring

On 03/29/2016 10:15 AM, Amos Jeffries wrote: > On 26/03/2016 3:28 a.m., Alex Rousskov wrote: >> the committed version is buggy IMHO > <http://pixy.kinkie.it/~kinkie/irc-logs/bot/index.php?d=2016-03-23> > > " > [20:07:04] > yadi > what I mean is the pools ar

Re: [squid-dev] [PATCH] BUg 4466: removal of -k kill command

On 03/29/2016 10:22 AM, Amos Jeffries wrote: > The Squid "-k kill" command line option is equivalent to "kill -9" on > whatever process has its PID in the .pid file. This is how "-k kill" is implemented, but this is not what it is meant to do IMO. > Since Squid gained multi-process SMP support

Re: [squid-dev] [PATCH] Bug 4438 - string pool refactoring

On 03/31/2016 04:13 AM, Amos Jeffries wrote: > On 31/03/2016 7:29 a.m., Alex Rousskov wrote: >> On 03/30/2016 11:15 AM, Amos Jeffries wrote: >>> On 30/03/2016 8:19 a.m., Alex Rousskov wrote: >>>> This committed code does nothing useful: Static variables, such as >

Re: [squid-dev] [PATCH] Increase request buffer size to 64kb

On 03/29/2016 06:06 PM, Nathan Hoad wrote: > This (very small) patch increases the request buffer size to 64kb, from 4kb. > -#define HTTP_REQBUF_SZ 4096 > +#define HTTP_REQBUF_SZ 65535 > In my testing, this increases throughput rather dramatically for > downloading large files: Based on

Re: [squid-dev] [PATCH] Increase request buffer size to 64kb

On 04/13/2016 08:22 AM, Amos Jeffries wrote: > Alex, have you had time to review this updated patch? Not yet. > For my part I am wondering if the class StoreIOBuffer needs to have move > constructor/assignment added now that getClientStreamBuffer() is > returning a temporary variable by-value.

[squid-dev] [PATCH] Accumulate less

Hello, The attached patch changes Squid to accumulate fewer unknown-size responses to avoid overwhelming disks. Patched Squid starts swapping out an unknown-size entry as soon as size-based cache_dir selection is no longer affected by the entry growth. If the entry eventually exceeds the

Re: [squid-dev] Piping existing SSL session into squid SSL session cache

On 04/27/2016 01:01 PM, Florian Schüttler wrote: > I have a scenario in which clients (<10) are connected to a server using > an application protocol inside a TLS connection. These clients should > now be able to reuse the existing TLS session for a TLS connection to > Squid running on the same

Re: [squid-dev] [PATCH] helpers queue update

On 04/23/2016 06:30 AM, Amos Jeffries wrote: > This is a hopefully minor update to the helper lookup queueing. > > It removes the only use of MEM_DLINK_NODE for custom link-list > implementation and replaces it all with a std::queue. > > Also, de-duplicates the *Dequeue() functions by merging

Re: [squid-dev] [PATCH] Remove SquidList / link_list

On 04/23/2016 06:20 AM, Amos Jeffries wrote: > On 15/04/2016 12:31 a.m., Amos Jeffries wrote: >> This patch replaces the remaining use of Squid custom link_list type >> with STL std::queue or std::list templates. Removing the now unneeded >> custom type completely. >> >> It builds on the previous

Re: [squid-dev] [PATCH] shell un-escaping squidclient -H option

On 05/19/2016 07:51 AM, Amos Jeffries wrote: > The squidclient -H parameter takes a string with some limited > shellescaped characters. Currently just \n was expanded to the CRLF > sequence. Other shell escaped characters were left untouched. > > However, to properly test headers containing weird

Re: [squid-dev] Bumping after peek and Splicing after stare

On 05/20/2016 09:45 AM, Amos Jeffries wrote: > IMO, if its a hack and causing trouble we should remove it. But as you > are the one who will probably be the one fixing it if it stays, thats > your call Chhristos. > > If you want to experiment, you could "#if 0" it for next weeks release > and see

[squid-dev] Do not load icons one character at a time

Hello, > revno: 14682 > committer: Alex Rousskov <rouss...@measurement-factory.com> > branch nick: trunk > timestamp: Fri 2016-05-20 12:16:19 -0600 > message: > Fixed icons loading speed. > > Since trunk r14100 (Bug 3875: bad mimeLoadIconFile error handling

Re: [squid-dev] Do not load icons one character at a time

On 05/23/2016 02:48 AM, Amos Jeffries wrote: > On 22/05/2016 5:03 a.m., Alex Rousskov wrote: >> On 05/21/2016 03:09 AM, Amos Jeffries wrote: >>> On 21/05/2016 6:25 a.m., Alex Rousskov wrote: >>>>> Since trunk r14100 (Bug 3875: bad mimeLoadIconFile error handling)

Re: [squid-dev] [PATCH] Delete cbdata-protected data --with-valgrind-debug

On 05/18/2016 01:14 PM, Amos Jeffries wrote: > On 18/05/2016 6:22 p.m., Alex Rousskov wrote: >> Valgrind was correctly reporting every cbdata allocation in trunk as >> leaking! >> I also fixed and polished cbdata debugging that was printing mismatching >> Alloca

Re: [squid-dev] [PATCH] mime unfolding

On 05/19/2016 07:29 AM, Amos Jeffries wrote: > On 19/05/2016 1:59 p.m., Alex Rousskov wrote: (A) >> while (!tk.atEnd()) { >> const SBuf all = tk.remaining(); >> const auto crLen = tk.skipOne(CR); // may not be there >> const auto lfL

Re: [squid-dev] [PATCH] Replace new/delete operators using modern C++ rules

On 04/11/2016 09:16 AM, Alex Rousskov wrote: > On 04/09/2016 10:50 PM, Amos Jeffries wrote: > >> In principle this is a great step forward, but I would like confirmation >> about the portability side of things before it actually gets merged. > Me too. [...] > > FWIW,

Re: [squid-dev] Bumping after peek and Splicing after stare

On 05/20/2016 05:12 AM, Christos Tsantilas wrote: > On 05/20/2016 12:26 PM, Amos Jeffries wrote: >> I would really like to see in the long >> term is peeking always at clientHello. > This is what fast-sni does! For the step1-to-step2 does not involved any > openSSL code. What Amos means is doing

Re: [squid-dev] [PATCH] adaptation_rep_header ACL

On 05/17/2016 08:24 AM, Steve Hill wrote: > This patch adds an adaptation_rep_header ACL type. This works in the > same way as the existing rep_header ACL, except rather than matching > HTTP response headers, it matches ICAP response headers. This allows > ICAP servers to pass data in the ICAP

Re: [squid-dev] [PATCH] Fast SNI peek

On 05/17/2016 08:39 AM, Amos Jeffries wrote: > To answer Christos' question; > For iostreams to print the pointer value in hex like seems to be wanted > here one has to make sure the pointer is a void* and not a type that can > be dereferenced. Otherwise the streams will try to display its

Re: [squid-dev] [PATCH] Fix maybeMakeSpaceAvailable() logic

On 05/15/2016 02:50 AM, Amos Jeffries wrote: > On 14/05/2016 9:00 a.m., Alex Rousskov wrote: >> Another subtle maybeMakeSpaceAvailable() problem was that the code >> contained its own buffer capacity increase algorithm (n^2 growth). >> However, increasing buffer capaci

[squid-dev] [PATCH] Fix maybeMakeSpaceAvailable() logic

Hello, This change fixes logic bugs that mostly affect performance: In micro-tests, this change gives 10% performance improvement for intercepted "fast peek at SNI and splice" SslBump configurations. Similar improvement is expected for future plain HTTP/2 parsers. trunk fsni fsni+

Re: [squid-dev] [PATCH] Fast SNI peek

On 05/13/2016 11:07 AM, Christos Tsantilas wrote: > mode | trunk | fast-sni > SS1 100% 100% > SS2 22% 69% > SS3 16% 26% The above [slightly adjusted by me] table needs an explanation and a few disclaimers. SSN in the first column means "splicing at SslBump stepN".

Re: [squid-dev] [PATCH] Accumulate less

On 04/27/2016 06:39 PM, Amos Jeffries wrote: > On 28/04/2016 5:14 a.m., Alex Rousskov wrote: >> Hello, >> >> The attached patch changes Squid to accumulate fewer unknown-size >> responses to avoid overwhelming disks. > +1. I just have some polish to consid

[squid-dev] HttpHeader::delById leaks

Hello, AFAICT, the following trunk code leaks every "deleted" header field: > HttpHeader::delById(Http::HdrType id) > { ... > //replace matching items with nil and count them > std::replace_if(entries.begin(), entries.end(), > [&](const HttpHeaderEntry *e) { > if (e &&

Re: [squid-dev] [PATCH] Retry cache peer DNS failures more frequently

On 05/10/2016 01:50 AM, Amos Jeffries wrote: > Then each peer gets its own re-lookup event scheduled If applied correctly, this approach would also solve the misapplication problem I described in my concurrent review. Unfortunately, it requires serious work. Fortunately, you have already

Re: [squid-dev] [PATCH] Retry cache peer DNS failures more frequently

On 05/09/2016 08:41 PM, Nathan Hoad wrote: > +NAME: cache_peer_negative_dns_ttl > +COMMENT: time-units > +TYPE: time_t > +LOC: Config.cachePeerNegativeDnsTtl > +DEFAULT: 1 minutes > +DOC_START > + How often to retry failed DNS lookups for cache peers. It is not actually clear what this means

Re: [squid-dev] [PATCH] libmem API cleanup pt2

On 04/12/2016 05:31 AM, Amos Jeffries wrote: > This is the first of the followup patches I promised when applying the > un-polished bug 4438 patch to 4.0.8. > > > Convert all the objects using the libmem "old API" for as-needed pools > to using the MEMPROXY_CLASS() API which is better designed

Re: [squid-dev] [PATCH] PeerConnector shuffling to libsecurity

On 04/14/2016 06:23 AM, Amos Jeffries wrote: > This patch shuffles the Ssl::PeerConnector to Security::TlsPeerEncryptor > and Ssl::BlindPeerConnector to Security::BlindTlsPeerEncryptor. I have already given up on fighting you about pointless and inconsistent SSL/TLS/Security renames, but please

Re: [squid-dev] [PATCH] Fetch missing certificates

On 07/14/2016 05:16 AM, Amos Jeffries wrote: > * the debugs lines indicating constructor and destructor have been run > need to be symmetrical and name the object type. > > - They are there for the find-alive.pl script, so need to match the > pattern it is searching for: > eg. debugs(33, 6,

Re: [squid-dev] Broken trunk after r14735

On 07/24/2016 01:04 AM, Amos Jeffries wrote: > does replacing "BIO_free" with "BIO_vfree" in the ssl/gadgets.h > definition of BIO_POinter fix this one? Same startup exception (quoted below) after patching trunk revision 14756 with > -typedef std::unique_ptr

Re: [squid-dev] [PATCH] Collapse internal revalidation requests (SMP-unaware caches)

On 07/23/2016 08:55 AM, Amos Jeffries wrote: > Applied to trunk as rev.14755 And thank you for fixing the override inconsistency bug. Alex. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [PATCH] Deletors for std::unique_ptr fixing r14735

On 07/29/2016 04:56 PM, Alex Rousskov wrote: > On 07/29/2016 12:29 PM, Alex Rousskov wrote: > I found two macro-free ways to do this. The so called "smart" one does > most of the work for us, but requires repeating the function name twice, > once with decltype() and once wit

Re: [squid-dev] [PATCH] Deletors for std::unique_ptr fixing r14735

On 07/29/2016 12:29 PM, Alex Rousskov wrote: > If possible, we should avoid macros and should learn how to use C++11 > correctly. In general, it makes little sense to suffer the pains of > switching to C++11 and then use macros for things C++11 is supposed to > provide or supp

Re: [squid-dev] [PATCH] Deletors for std::unique_ptr WAS: Re: Broken trunk after r14735

On 07/30/2016 07:03 AM, Amos Jeffries wrote: > On 30/07/2016 6:29 a.m., Alex Rousskov wrote: >> On 07/29/2016 09:27 AM, Amos Jeffries wrote: >>>>> typedef std::unique_ptr<BIO, std::function<decltype(BIO_free)>> >>>>> BIO_Pointer; >> >

Re: [squid-dev] [PATCH] Make Squid death due to overloaded helpers optional

On 08/09/2016 06:19 PM, Henrik Nordström wrote: > tis 2016-08-09 klockan 11:47 -0600 skrev Alex Rousskov: >> >> Yep, that matches both my understanding and motivation to return ERR >> in the explicitly configured on-persistent-overload=err case. > I'd say make it configur

Re: [squid-dev] [PATCH] Make Squid death due to overloaded helpers optional

On 08/11/2016 06:53 AM, Amos Jeffries wrote: > On 11/08/2016 11:50 p.m., Eduard Bagdasaryan wrote: >> 2016-08-10 19:03 GMT+03:00 Alex Rousskov >> <rouss...@measurement-factory.com>: >> >>> As Amos has noted, we do need to restore the old "unknown&q

Re: [squid-dev] [PATCH] Make Squid death due to overloaded helpers optional

On 08/09/2016 11:39 AM, Amos Jeffries wrote: > On 10/08/2016 4:41 a.m., Alex Rousskov wrote: >> On 08/09/2016 05:38 AM, Eduard Bagdasaryan wrote: >>> On 08/08/2016 02:17 PM, Amos Jeffries wrote: >>>> * helper::SubmissionFailure is also changing what was previously &g

Re: [squid-dev] Broken trunk after r14735, r14726

On 07/20/2016 10:04 AM, Christos Tsantilas wrote: > Why do we need common types for both SDKs? You have answered your own question below: > The only type needed by squid for openSSL is the "SSL *" which is stored > inside fde class. And the gnutls_session_int for gnutls. These are > should be

Re: [squid-dev] [RFC] [PREVIEW] LockingPointer round 3.

On 07/21/2016 07:58 AM, Amos Jeffries wrote: > void resetWithoutLocking(T *t) { > +#if USE_OPENSSL > +assert(!t || t->references > 0); > +assert(!raw || raw->references > 0); > +if (raw && t == raw) { > +assert(raw->references > 1); // us plus caller locks

Re: [squid-dev] [PATCH] Some failed transactions are not logged

On 07/20/2016 05:27 PM, Eduard Bagdasaryan wrote: > We do not have a 'getter' for receivedFirstByte_. It easy to add it > of course, but I assume the current receivedFirstByte() should be > refactored then and renamed. Adding a getter is not going to be easy, is outside your project scope, and

Re: [squid-dev] [PATCH] Some failed transactions are not logged

On 07/17/2016 03:34 AM, Amos Jeffries wrote: > On 16/07/2016 2:40 a.m., Eduard Bagdasaryan wrote: >> +// do not log connections that sent us no bytes (TODO: make >> configurable) >> +// do not log connections that closed after a transaction (those are >> normal) >> +// XXX: We assume

Re: [squid-dev] Broken trunk after r14735, r14726

On 07/18/2016 08:49 AM, Christos Tsantilas wrote: > On 07/18/2016 02:12 PM, Christos Tsantilas wrote: >> On 07/16/2016 03:56 PM, Amos Jeffries wrote: >>> On 16/07/2016 7:02 a.m., Alex Rousskov wrote: >>>> * After r14726 (GnuTLS: support for TLS session resume):

Re: [squid-dev] [RFC] "Splicing" bumped requests to resolve\workaround WebSockets issues.

On 07/17/2016 02:34 PM, Eliezer Croitoru wrote: > I remember something's vaguely and this is why I didn't quote anything. > I tried searching for something in the squid-dev list or irc but I couldn't > found it. For the future, I hope you will document your vague memories without saying that

Re: [squid-dev] Broken trunk after r14735, r14726

On 07/18/2016 05:12 AM, Christos Tsantilas wrote: > I must say that I am worrying a lot for all of these changes. > It is very difficult for me to follow them, and already I have > difficulties to read and debug squid openSSL relate code. > > We are using our own naming scheme for openSSL

Re: [squid-dev] [RFC] reduce MISS on transients collision

On 07/17/2016 05:01 AM, Amos Jeffries wrote: > I've just been looking at the Store::Controller::find() implementation > and it struck me that if the transients lookup has an error the object > will fail to HIT on any existing cache entries. If the transients table tells us that the transient

Re: [squid-dev] [RFC] "Splicing" bumped requests to resolve\workaround WebSockets issues.

On 07/15/2016 04:29 AM, Eliezer Croitoru wrote: > The issue: > > Clients are issuing secured connections which contains WebSockets > internally and squid HTTP parsing breaks these connections. > Another related issue which deserves attention: > > Certificate pinning and connection breakage. >

Re: [squid-dev] Broken trunk after r14735, r14726

On 07/19/2016 12:52 AM, Amos Jeffries wrote: > 4) designing our code to use an abstraction API that renames all the > library structures and functions to some thing we understand easier **. If multi-library support is needed, and there is no existing usable generic wrapper, then this is the only

Re: [squid-dev] [PATCH] Some failed transactions are not logged

On 07/19/2016 08:10 AM, Amos Jeffries wrote: > On 20/07/2016 1:44 a.m., Eduard Bagdasaryan wrote: >> 2016-07-19 16:17 GMT+03:00 Amos Jeffries: >>> Is this patch going to include the new config option to prevent logging >>> the new things? or do it in a followup? >> >> For now we are not planning

Re: [squid-dev] Broken trunk after r14735, r14726

On 07/19/2016 01:14 AM, Amos Jeffries wrote: > PS. Alex is the other r14735 issue still present in current trunk now > that r14726 is reverted? No, same problem with trunk r14748: > terminate called after throwing an instance of 'std::bad_function_call' > what(): bad_function_call > >

<    1   2   3   4   5   6   7   8   >