MEDIUM: stream: fix client-fin/server-fin handling
A tcp half connection can cause 100% CPU on expiration.
On Thu, Sep 14, 2017 at 6:59 PM, Pean, David S.
mailto:david.s.p...@espn.com>> wrote:
Hello!
I am using a TCP front-end that potentially keeps connections open for several
hou
Hello!
I am using a TCP front-end that potentially keeps connections open for several
hours, while also frequently issuing reloads due to an id to server mapping
that is changing constantly. This causes many processes to be running at any
given time, which generally works as expected. However,
On Thu, May 8, 2014 at 6:01 PM, Willy Tarreau wrote:
> Hi David,
>
> (.)
>
> OK.
>
> I'd like to issue dev25 this week-end since we fixed a number of nasty
> issues. Do you think you can make the adjustments by then ? I'd really
> like to merge your work so that you have something to play w
Please find attached a patch that fully implements PROXY Protocol V2, and
adds initial extensions to include some SSL information. I have updated
the configuration.txt and proxy-protocol.txt files. The patch should apply
to the latest code in git. I believe I have incorporated all suggestions
fr
Hi Willy--
Here's my latest on extending Proxy Protocol V2.
I'm still testing this, but I would like to solicit any feedback that
you may have.
I believe I have incorporated all of your comments to date.
So far, I have implemented CN as a first sub-vector. I'm willing to
write a couple
On Wed, Apr 23, 2014 at 4:24 PM, Willy Tarreau wrote:
> On Wed, Apr 23, 2014 at 04:19:17PM -0400, David S wrote:
> > On Wed, Apr 23, 2014 at 5:45 AM, Willy Tarreau wrote:
> >
> > > (...)
> > > Otherwise your patch looks fine. Do you want me to merge it ? If so,
On Wed, Apr 23, 2014 at 5:45 AM, Willy Tarreau wrote:
> (...)
> Otherwise your patch looks fine. Do you want me to merge it ? If so,
> please could you provide a commit message with it ?
>
> Thanks,
> Willy
>
First, I'll update the documentation to keep it in sync with the code.
Thinking ahead
>
> (...)
> Yes sure, for this there's a "target" pointer in the connection, it
> points to an enum obj_type* which lets us check what the target is.
>
> So basically to get a server pointer, you just need to use this :
>
> srv = objt_server(conn->target);
>
> If the target is not a server, srv w
>
> (...)
> > /* returns true is the transport layer is ready */
> > static inline int conn_xprt_ready(const struct connection *conn)
> > diff --git a/include/types/connection.h b/include/types/connection.h
> > index 5341a86..b3b85ab 100644
> > --- a/include/types/connection.h
> > +++ b/include/t
As a foundation for extending the proxy-protocol to include additional
information, I've implemented version 2 of the proxy protocol. As we
discussed in the "Extending PROXY protocol for SSL" thread, I made one
change to the protocol.
Version and Command are combined into one byte.
Length is now
On Wed, Apr 16, 2014 at 5:44 PM, Willy Tarreau wrote:
> (...)
> We can also decide that we don't implement the extensions in v1 which
> will motivate adoption for the new v2.
> (...)
>
> What's your opinion ?
>
> Willy
>
> I prefer to make the extension v2 only, mostly because I don't want to
wri
On Tue, Apr 15, 2014 at 6:13 AM, Willy Tarreau wrote:
> Hi David,
>
> On Mon, Apr 14, 2014 at 09:54:19PM -0400, David S wrote:
> > Hello--
> > Part of my solution uses a non-HTTP protocol. My backend server need
> > L3/L4 information, so the PROXY protocol is
Hello--
Part of my solution uses a non-HTTP protocol. My backend server need
L3/L4 information, so the PROXY protocol is a perfect fit. In addition to
TCP and IP addresses, my backend server needs information from the client
SSL connection. So, I would like to extend the PROXY protocol.
Sorry, I missed that when rebasing. I'm not sure how.
SMP_T_CSTR needs to be changed to SMP_T_STR
On Wed, Apr 9, 2014 at 8:45 AM, Lukas Tribus wrote:
> Hi Willy, hi David,
>
>
> > On Tue, Apr 08, 2014 at 06:48:47PM -0400, David S wrote:
> >> Thank you Lukas.
&
Thank you Lukas.
Here is the rebased patch.
I also made one correction, I had added ssl_fc_unique_id as an ACL keyword,
but that does not make sense. I removed that added line from my patch.
Answering a question I received offline:
base64 is the common way to encode this value. SCRAM (RFC 5802),
Hello--
The TLS unique id, or unique channel binding, is a byte string that can
be pulled from a TLS connection and it is unique to that connection. It
is defined in RFC 5929 section 3. The value is used by various upper layer
protocols as part of an extra layer of security. For example XMPP
the client
certificate. The maximum length of a CN is 64 bytes.
Please let me know your thoughts and what procedure I should follow to
submit my patch.
Thanks,
David
On Thu, Jan 30, 2014 at 3:10 AM, Willy Tarreau wrote:
> Hi David,
>
> On Wed, Jan 29, 2014 at 10:53:22PM -0500, David S wrote
I want to use HAProxy to terminate my incoming SSL connections and forward
the messages to my server application. My challenge is that my
application needs information from the client certificates.
The Proxy Protocol is one way that connection information can be forwarded
from HAProxy to the rec
18 matches
Mail list logo
