Re: [squid-dev] [PATCH] LockingPointer API update

[Amos Jeffries]

On 23/06/2016 4:58 a.m., Alex Rousskov wrote:
> On 06/22/2016 05:29 AM, Amos Jeffries wrote:
>> On 22/06/2016 10:42 p.m., Christos Tsantilas wrote:
>>> On 06/22/2016 07:32 AM, Amos Jeffries wrote:
 1) PeekingPeerConnector::handleServerCertificate() doing
 serverBump->serverCert.reset(serverCert.release())

 On much closer inspection it appears not a bug. But is doing move
 semantics without a move operator relying heavily on specific
 implementation detail of TidyPointer API exposure.
> 
>>> This is not bug. The call
>>> newServerCertPointer.reset(oldServerCertPointer.release())
>>> just moves the X509 object with the current locks to the
>>> newServerCertPointer.
> 
>> Yeah. Thats move semantics.
> 
> Agreed.
> 
> 
>> LockingPointer has a move assignment operator for doing that in clearer
>> way now in trunk - and 3.5 when built with C++11 compiler.
> 
> At the risk of sounding like a broken record, I have to note that a move
> assignment operator is an _optimization_. It is _not_ a clearer way of
> doing anything. It is a cheaper way. It is not triggered except in some
> special circumstances [that are usually absent in the current
> LockingPointer code]. A move method alone is neither necessary nor
> usually sufficient for move semantics support.
> 
> Even if all non-clearing LockingPointer::reset() calls are there to
> _move_ things, we still cannot merge reset() and resetAndLock() because
> it would be trivial for the code to accidentally call the assignment
> operator (that locks) instead of the move assignment operator (that does
> not lock).

As you said the actual move is an optimization. If something breaks by
doing a copy and extra lock - then its not suitabel for using
LockingPointer in the first place.

The lines (quoted below here) which sparked this side discussion can
clearly be implemented with either assignment operator and both work
properly.

* All that happens on the copy-assign "slow" path is one extra
lock+unlock action.

* the use of constructor and assign [ X = construct(Y); ] is one of the
patterns the compiler deduces to be a move operator.

So the below simple logic should compile to the same thing the arcane
mix of reset+release did.

> 
>> The above code becomes:
>>
>>   Security::CertPointer serverCert;
>>   if (...) {
>> // We need to lock here because the destructor of
>> // serverCert will call X509_free and decrease the lock
>>
>> // operator =() copy-assign does the lock stuff
>>
>> serverCert = serverBump->serverCert;
>>
>>   } else {
>> // We do not need to lock here, the SSL_get_peer_certificate
>> // already increases the clock counter and we have to
>> // free with X509_free.
>>
>> // CertPointer() constructor builds object without locking it
>> // assuming SSL_get_peer_certificate() did the lock for it.
>>
>> // operator =() move-assign or copy-assign does the lock stuff
>>
>> serverCert = Security::CertPointer(SSL_get_peer_certificate(ssl)));
>>   }
>>   // serverCert::~serverCert() called on function
>>   // leave, calling X509_free.
> 
> As Christos has said or implied, this approach assumes that
> Security::CertPointer is an assignable pointer (e.g., LockingPointer)
> and not a TidyPointer that does not have an assignment operator (by
> design). There is nothing wrong with that approach per se, but this is
> not what your patch (and approach known as #1) was about.
> 

Nod. I am taking advantage of the fact that currently GnuTLS does not do
bumping so this code is wrapped in USE_OPENSSL.

I dont't see that as a problem since the CertPointer type will need to
be converted to GnuTLS-enabled LockingPointer in order for GnuTLS to use
the feature this code is about.

My experimental build the past few hours has confirmed that all current
LockingPointer uses are OpenSSL-specific or already using a temporary
'-1' LockingPointer for GnuTLS.


> If you are switching to approach #2,

I'm currently experimenting with the ideas to see what a transition
needs to look like.

> then I agree with Christos that we
> should remove TidyPointer as a LockingPointer parent.

Doing some experimental builds of that now. Not quite a full split, but
with TidyPointer as protected rather than public inheritence.

> LockingPointer
> should use TidyPointer as the type of its pointer data member instead:
> 
>   template <...>
>   class LockingPointer {
>   ...
>   private:
>   TidyPointer<...> pointer; ///< owns the object we lock
>   };
> 

Hmm. TidyPointer alone is essentially a std::unique_ptr with custom
delete. We can probably drop TidyPointer from trunk entirely.

> 
>> But, the GnuTLS builds will need an equivalent Pointer with a different
>> lock action to handle session pointers.
> 
> Besides the TidyPointer disassociation sketched above, I suggest
> replacing the "int lock" LockingPointer template parameter with a
> locking function parameter. With some [trivial] wrappers for OpenSSL's
> "CRYPTO_add(..., lock)"

Re: [squid-dev] [PATCH] LockingPointer API update

[Alex Rousskov]

On 06/22/2016 05:29 AM, Amos Jeffries wrote:
> On 22/06/2016 10:42 p.m., Christos Tsantilas wrote:
>> On 06/22/2016 07:32 AM, Amos Jeffries wrote:
>>> 1) PeekingPeerConnector::handleServerCertificate() doing
>>> serverBump->serverCert.reset(serverCert.release())
>>>
>>> On much closer inspection it appears not a bug. But is doing move
>>> semantics without a move operator relying heavily on specific
>>> implementation detail of TidyPointer API exposure.

>> This is not bug. The call
>> newServerCertPointer.reset(oldServerCertPointer.release())
>> just moves the X509 object with the current locks to the
>> newServerCertPointer.

> Yeah. Thats move semantics.

Agreed.


> LockingPointer has a move assignment operator for doing that in clearer
> way now in trunk - and 3.5 when built with C++11 compiler.

At the risk of sounding like a broken record, I have to note that a move
assignment operator is an _optimization_. It is _not_ a clearer way of
doing anything. It is a cheaper way. It is not triggered except in some
special circumstances [that are usually absent in the current
LockingPointer code]. A move method alone is neither necessary nor
usually sufficient for move semantics support.

Even if all non-clearing LockingPointer::reset() calls are there to
_move_ things, we still cannot merge reset() and resetAndLock() because
it would be trivial for the code to accidentally call the assignment
operator (that locks) instead of the move assignment operator (that does
not lock).


> The above code becomes:
> 
>   Security::CertPointer serverCert;
>   if (...) {
> // We need to lock here because the destructor of
> // serverCert will call X509_free and decrease the lock
> 
> // operator =() copy-assign does the lock stuff
> 
> serverCert = serverBump->serverCert;
>
>   } else {
> // We do not need to lock here, the SSL_get_peer_certificate
> // already increases the clock counter and we have to
> // free with X509_free.
> 
> // CertPointer() constructor builds object without locking it
> // assuming SSL_get_peer_certificate() did the lock for it.
> 
> // operator =() move-assign or copy-assign does the lock stuff
> 
> serverCert = Security::CertPointer(SSL_get_peer_certificate(ssl)));
>   }
>   // serverCert::~serverCert() called on function
>   // leave, calling X509_free.

As Christos has said or implied, this approach assumes that
Security::CertPointer is an assignable pointer (e.g., LockingPointer)
and not a TidyPointer that does not have an assignment operator (by
design). There is nothing wrong with that approach per se, but this is
not what your patch (and approach known as #1) was about.

If you are switching to approach #2, then I agree with Christos that we
should remove TidyPointer as a LockingPointer parent. LockingPointer
should use TidyPointer as the type of its pointer data member instead:

  template <...>
  class LockingPointer {
  ...
  private:
  TidyPointer<...> pointer; ///< owns the object we lock
  };


> But, the GnuTLS builds will need an equivalent Pointer with a different
> lock action to handle session pointers.

Besides the TidyPointer disassociation sketched above, I suggest
replacing the "int lock" LockingPointer template parameter with a
locking function parameter. With some [trivial] wrappers for OpenSSL's
"CRYPTO_add(..., lock)", it might work well for both GnuTLS and OpenSSL
needs.


HTH,

Alex.

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [PATCH] LockingPointer API update

[Alex Rousskov]

On 06/22/2016 08:31 AM, Christos Tsantilas wrote:
> On 06/22/2016 04:02 AM, Alex Rousskov wrote:
>> I have attached a list of relevant trunk calls. It may be incomplete.
>>
> I run over the list to check for problems.
> Also I checked the resetAndLock calls, looks ok.

Thank you!


> However the true is that the reset/resetAndLock scheme for
> lockingPointer is confusing.

Agreed. AFAICT, the primary source of that confusion is inconsistencies
in OpenSSL locking patterns. We can reduce that confusion by providing
resetWithoutLocking/resetAndLock pair instead of reset/resetAndLock.

If we really want to remove confusion, we would have to provide C++
wrappers for all relevant OpenSSL objects and hide locking inside our
wrapping code instead of requiring innocent _callers_ to worry about it.
I think doing so would be worthwhile in general, but it is a large
polishing project that we may not be able to finish soon because of the
more important projects standing in the way.

Alex.

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [PATCH] LockingPointer API update

[Christos Tsantilas]

On 06/22/2016 04:02 AM, Alex Rousskov wrote:

I have attached a list of relevant trunk calls. It may be incomplete.


I run over the list to check for problems.
Also I checked the resetAndLock calls, looks ok.
However the true is that the reset/resetAndLock scheme for 
lockingPointer is confusing.






___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [PATCH] LockingPointer API update

[Christos Tsantilas]

On 06/22/2016 02:29 PM, Amos Jeffries wrote:

On 22/06/2016 10:42 p.m., Christos Tsantilas wrote:

On 06/22/2016 07:32 AM, Amos Jeffries wrote:

On 22/06/2016 1:02 p.m., Alex Rousskov wrote:

On 06/21/2016 04:00 AM, Amos Jeffries wrote:

...

In the patch I'm working on now its looking very much like we can drop
the reset() method for these instances and just use a temporary local
object. Like so:

The above code becomes:

   Security::CertPointer serverCert;
   if (...) {
 // We need to lock here because the destructor of
 // serverCert will call X509_free and decrease the lock

 // operator =() copy-assign does the lock stuff

 serverCert = serverBump->serverCert;

   } else {
 // We do not need to lock here, the SSL_get_peer_certificate
 // already increases the clock counter and we have to
 // free with X509_free.

 // CertPointer() constructor builds object without locking it
 // assuming SSL_get_peer_certificate() did the lock for it.

 // operator =() move-assign or copy-assign does the lock stuff

 serverCert = Security::CertPointer(SSL_get_peer_certificate(ssl)));
   }
   // serverCert::~serverCert() called on function
   // leave, calling X509_free.


So long as we only construct LockingPointer from freshly minted OpenSSL
raw-pointers that have an OpenSSL set lock. Then we do not need the
non-locking reset() operation.
We do need the locking reset*() method for the cases where the raw
pointer is not locked by the library.


If we are going to implement and use "=" operator instead of reset 
method, then we should implement LockingPointer as a new full locking 
pointer, not a TidyPointer class.


I think this is will work.
The copy contructor and '=' operators should increase the lock, but a 
cunstructor which takes as argument the raw openSSL object (eg an "X509 
*") should not increase the lock.
However this is maybe is more confusing than the existing 
reset/resetAndLock scheme.


But I believe, this is will not solve your original problem, where you 
needed TidyPointer instead of LockingPointer.

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] HTTP2 push related question.

[Amos Jeffries]

On 22/06/2016 8:28 p.m., Eliezer Croitoru wrote:
> I am having troubles in understanding the benefits of HTTP 2 push messages
> and I am looking a starter point on how to look at the subject.

> I am sure that there are applicable usage for it and I remember that xmpp
> and many other protocols are using this feature already.
> But I still do not understand in what way it will extend the protocol?

If you connect to a HTTP/1 server and tell it only that you want
http://example.com/index.html. That is all that will come back.

With HTTP/2 PUSH the server will inform about /some-scrip.js, logo.png,
etc. that were referenced by the index.html, and start to send them back
as well.

As you mentioned protocols like XMPP, they can be done more efficiently
over this type of one-request equals N-things-happen communication than
over HTTP/1 messaging. The parallel + multiplex nature of the streams
also helps them out a lot more than HTTP/1 synchronous messages.



> The situation of a PUSH as I understand it would be when you kind of "trust"
> the origin server and for specific applications.

Trust is not a direct part of the equation. It is only there in the fact
that 1) the server emitting the PUSH should be the origin for the domain
of the request that originally triggered the PUSH, and 2) the resources
PUSH'ed need to be related (same authority IIRC) to the initial request.


PUSH is aimed at removing the needs behind some existing services
behaviour which is causing problems in the name of latency gains.

Specifically the ones bundling up multiple response objects into a
tarball or similar. So the client asks for only thing (after the HTML
page that uses it) and decompresses all the display pieces dynamically
in the browser memory to generate the page. Often only a small part of
the bundle is actually needed, and the parts individually could be much
better cached separately if they were allowed to.

Or worse, the page has a script running up a WebSockets channel that
transfer the objects in a custom way incompatible with HTTP caching.



> Today normal web pages are already pushing data to the web browsers but with
> PUSH as I understand it means that for example a 1GB file can be pushed to
> the client.

Any size of content up to infinity can be PUSH'ed back.

If you look into exactly _how_ those services are doing the 'push' its
usually something very inefficient, complex and/or difficult. Such as
the ways I mention above.

Theres a need there that HTTP/1 does not provide a solution to. HTTP/2
tries to improve the situation.

Amos

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [PATCH] avoid flooding cache.log with "uninitialized value" messages from ext_wbinfo_group_acl helper script

[Amos Jeffries]

On 22/06/2016 7:22 p.m., Vieri wrote:
> Hi,
>
> With default debug_options too many "uninitialized value" messages in
/var/log/squid/cache.log;
> Use of uninitialized value $ans in concatenation (.) or string at
/usr/libexec/squid/ext_wbinfo_group_acl line 204,  line 44.
> Use of uninitialized value $ans in concatenation (.) or string at
/usr/libexec/squid/ext_wbinfo_group_acl line 205,  line 44.
>
> Minor issue fixed with this patch.

Thank you.

I was just double-checking this before applying and it looks to me like
$ans should never be unset in a properly configured group helper.

What does your squid.conf contain for this helper?
 (both the external_acl_type and the "acl ... external" lines using it
please)

And what does the debug output the helper injects into the log along
with those perl warnings look like?
 (should be something like "Sending ... to Squid".)


I'm asking because an empty line "\n" is not a valid response from an
external ACL helper. What the $ans needs to be initialized to depends on
whether it is a misconfiguration or something else resulting in the perl
warning.

PS. sorry for not noticing this earlier when you wrote to squid-users.

Amos

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [PATCH] LockingPointer API update

[Amos Jeffries]

On 22/06/2016 10:42 p.m., Christos Tsantilas wrote:
> On 06/22/2016 07:32 AM, Amos Jeffries wrote:
>> On 22/06/2016 1:02 p.m., Alex Rousskov wrote:
>>> On 06/21/2016 04:00 AM, Amos Jeffries wrote:
>>
>> The two I saw were:
>>
>> 1) PeekingPeerConnector::handleServerCertificate() doing
>> serverBump->serverCert.reset(serverCert.release())
>>
>> On much closer inspection it appears not a bug. But is doing move
>> semantics without a move operator relying heavily on specific
>> implementation detail of TidyPointer API exposure.
> 
> This is not bug. The call
> newServerCertPointer.reset(oldServerCertPointer.release())
> just moves the X509 object with the current locks to the
> newServerCertPointer.

Yeah. Thats move semantics.

LockingPointer has a move assignment operator for doing that in clearer
way now in trunk - and 3.5 when built with C++11 compiler.



>>
>> 2) PeekingPeerConnector::serverCertificateVerified() doing two different
>> reset() vs resetAndLock() depending on the data source.
>>
>> The OpenSSL docs do say the call increments a reference count itself.
>> But I still think this is leaking. Since we explicitly unlock on
>> destruct as well as calling the necessary free API method in OpenSSL.
> 
> I do not think that this is leaking here.
> The code is the following:
> 
>   Security::CertPointer serverCert;
>if (...) {
>// We need to lock here because the destructor of
>// serverCert will call X509_free and will
>// decrease the lock of the
>serverCert.resetAndLock(serverBump->serverCert.get());
>} else {
>// We do not need to lock here, the SSL_get_peer_certificate
>// already increases the clock counter and we have to
>// free with X509_free.
>serverCert.reset(SSL_get_peer_certificate(ssl));
>}
>// serverCert::~serverCert() called on function
>// leave, calling X509_free.
> 
> 
> For LockingCounter we need both a reset and a resetAndLock method to
> correctly using it with openSSL library. There are cases where an
> openSSL call increases the locking counter for the object it returns and
> other cases where it doesn't.

In the patch I'm working on now its looking very much like we can drop
the reset() method for these instances and just use a temporary local
object. Like so:

The above code becomes:

  Security::CertPointer serverCert;
  if (...) {
// We need to lock here because the destructor of
// serverCert will call X509_free and decrease the lock

// operator =() copy-assign does the lock stuff

serverCert = serverBump->serverCert;

  } else {
// We do not need to lock here, the SSL_get_peer_certificate
// already increases the clock counter and we have to
// free with X509_free.

// CertPointer() constructor builds object without locking it
// assuming SSL_get_peer_certificate() did the lock for it.

// operator =() move-assign or copy-assign does the lock stuff

serverCert = Security::CertPointer(SSL_get_peer_certificate(ssl)));
  }
  // serverCert::~serverCert() called on function
  // leave, calling X509_free.


So long as we only construct LockingPointer from freshly minted OpenSSL
raw-pointers that have an OpenSSL set lock. Then we do not need the
non-locking reset() operation.
We do need the locking reset*() method for the cases where the raw
pointer is not locked by the library.

> 
> The LockingPointer is not perfect. But it is a class used and adjusted
> to be used for openSSL related objects. OpenSSL is a C library and it is
> not easy to convert openSSL objects to equivalent C++ objects.
> 
> I must also note that the locking pointer is not used only for X509
> objects but for other objects too.
> 
> In a point of view the LockingPointer should never moved under the
> Security and should be used only for openSSL related code.

Yes and no.

It got moved to src/security/ so objects of its type could be used by
the src/security/ code in builds where the src/ssl/ path is not compiled.

If this attempt to get TidyPointer able to be used as a seamless
replacement in the generic libsecurity API then LockingPointer can
probably go back there. But not until that is true.

But, the GnuTLS builds will need an equivalent Pointer with a different
lock action to handle session pointers.

Amos

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [PATCH] LockingPointer API update

[Christos Tsantilas]

On 06/22/2016 07:32 AM, Amos Jeffries wrote:

On 22/06/2016 1:02 p.m., Alex Rousskov wrote:

On 06/21/2016 04:00 AM, Amos Jeffries wrote:


The two I saw were:

1) PeekingPeerConnector::handleServerCertificate() doing
serverBump->serverCert.reset(serverCert.release())

On much closer inspection it appears not a bug. But is doing move
semantics without a move operator relying heavily on specific
implementation detail of TidyPointer API exposure.


This is not bug. The call
newServerCertPointer.reset(oldServerCertPointer.release())
just moves the X509 object with the current locks to the 
newServerCertPointer.





2) PeekingPeerConnector::serverCertificateVerified() doing two different
reset() vs resetAndLock() depending on the data source.

The OpenSSL docs do say the call increments a reference count itself.
But I still think this is leaking. Since we explicitly unlock on
destruct as well as calling the necessary free API method in OpenSSL.


I do not think that this is leaking here.
The code is the following:

  Security::CertPointer serverCert;
   if (...) {
   // We need to lock here because the destructor of
   // serverCert will call X509_free and will
   // decrease the lock of the
   serverCert.resetAndLock(serverBump->serverCert.get());
   } else {
   // We do not need to lock here, the SSL_get_peer_certificate
   // already increases the clock counter and we have to
   // free with X509_free.
   serverCert.reset(SSL_get_peer_certificate(ssl));
   }
   // serverCert::~serverCert() called on function
   // leave, calling X509_free.


For LockingCounter we need both a reset and a resetAndLock method to 
correctly using it with openSSL library. There are cases where an 
openSSL call increases the locking counter for the object it returns and 
other cases where it doesn't.


The LockingPointer is not perfect. But it is a class used and adjusted 
to be used for openSSL related objects. OpenSSL is a C library and it is 
not easy to convert openSSL objects to equivalent C++ objects.


I must also note that the locking pointer is not used only for X509 
objects but for other objects too.


In a point of view the LockingPointer should never moved under the 
Security and should be used only for openSSL related code.




___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] Dealing with RegisteredHeadersHash.gperf

[Kinkie]

On Wed, Jun 22, 2016 at 6:42 AM, Amos Jeffries  wrote:

> On 22/06/2016 5:13 a.m., Eduard Bagdasaryan wrote:
> > Hello,
> >
> > In my current task I need to change some of header definitions, but it is
> > unclear how to do this correctly. My understanding is that I need to
> > modify http/RegisteredHeadersHash.gperf, and then run
> > "make gperf-files" to generate RegisteredHeadersHash.cci. Is this
> correct?
>
> I believe so, though I've not done it myself yet. Kinkie knows more if
> he replies.
>

Yes, that's it. Remember that - contrary to what we do in many other
similar cases - the .cci file needs to be committed to the repository.


>
> > The http/RegisteredHeadersHash.gperf has a comment that it was
> > auto-generated
> > from RegisteredHeadersHash.gperf. How could it be generated from itself?
>
> Its not. That %{ ...}% is a block of data to be inserted verbatum into
> the output file at the same (top) position. Bit unfortunate that we had
> to do it that way.
>

Yes.
-- 
Francesco
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] HTTP2 push related question.

[Eliezer Croitoru]

I am having troubles in understanding the benefits of HTTP 2 push messages
and I am looking a starter point on how to look at the subject.
I am sure that there are applicable usage for it and I remember that xmpp
and many other protocols are using this feature already.
But I still do not understand in what way it will extend the protocol?
The situation of a PUSH as I understand it would be when you kind of "trust"
the origin server and for specific applications.
Today normal web pages are already pushing data to the web browsers but with
PUSH as I understand it means that for example a 1GB file can be pushed to
the client.

Any redirections are welcome,
Eliezer


Eliezer Croitoru  
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il
 

<>___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [squid-dev] [RFC] ICAP external acl services

[Eliezer Croitoru]

Thanks for the comments.

It's much clearer now then before.

The next is the answer to all of my questions:

Simplicity. Speed. Flexibility.

And not having to teach admin a major compicated protocol just 
to script
a yes/no decision. The basic helper I/O protocol we have 
already seems
to be blowing some peoples minds.

For me it didn't blow the mind at start but later things got a bit complicated 
with the growing complexity of things.
But when someone answers something it helps for many more then just plain docs.

Eliezer 
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] [PATCH] avoid flooding cache.log with "uninitialized value" messages from ext_wbinfo_group_acl helper script

[Vieri]

(sorry if I previously posted in HTML format)

Hi,

With default debug_options too many "uninitialized value" messages in 
/var/log/squid/cache.log;
Use of uninitialized value $ans in concatenation (.) or string at 
/usr/libexec/squid/ext_wbinfo_group_acl line 204,  line 44.
Use of uninitialized value $ans in concatenation (.) or string at 
/usr/libexec/squid/ext_wbinfo_group_acl line 205,  line 44.

Minor issue fixed with this patch.

Thanks,

Vieri

ext_wbinfo_group_acl.pl.in.diff
Description: Binary data
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[squid-dev] [PATCH] avoid flooding cache.log with "uninitialized value" messages from ext_wbinfo_group_acl helper script

[Vieri]

Hi,

With default debug_options too many "uninitialized value" messages in 
/var/log/squid/cache.log;
Use of uninitialized value $ans in concatenation (.) or string at 
/usr/libexec/squid/ext_wbinfo_group_acl line 204,  line 44.
Use of uninitialized value $ans in concatenation (.) or string at 
/usr/libexec/squid/ext_wbinfo_group_acl line 205,  line 44.

Minor issue fixed with this patch.

Thanks,

Vieri



ext_wbinfo_group_acl.pl.in.diff
Description: Binary data
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev