possible to capture custom response header for http logs?

2017-10-23 Thread David Birdsong 
I'm using haproxy to create an identifier using an upstream response header
like so:

http-response set-header X-R-ID %[res.hdr("X-Used-Params"),djb2(1),hex]

I'm having trouble getting haproxy to log this value with the additional
capture header that should get routed to my custom http log:

capture response header X-R-ID len 16

Does http-response set-header run too late to be captured for logging?

Re: Tagging a 1.8 release?

2017-10-23 Thread Jonathan Matthews 
On 20 October 2017 at 17:17, Willy Tarreau  wrote:
> I'd like to collect all the pending stuff by the end of next week and issue
> a release candidate. Don't expect too much stability yet though, but your
> tests and reports will obviously be welcome.

Are you still finger-in-the-air aiming for a "November 2017" 1.8? I
don't recall where I saw that quote, but I'm pretty sure it was an
intention mentioned ... /somewhere/!

No pressure - just wondering :-)

J

Re: [PATCH] MINOR: ssl: ocsp response with 'revoked' status is correct

2017-10-23 Thread Sander Hoentjen 
Hi Willy,


On 10/22/2017 10:02 AM, Willy Tarreau wrote:
> Hi Manu,
>
> On Tue, Oct 10, 2017 at 03:44:07PM +0200, Emmanuel Hocdet wrote:
>> Hi Emeric,
>>
>>
>> ocsp_status can be 'good', 'revoked', or 'unknown'. 'revoked' status
>> is a correct status and ocsp response should not be dropped.
>> In case of certificate with OCSP must-stapling extension, response with
>> 'revoked' status must be provided as well as 'good' status.
> given that it looks like a bug, I merged it and re-tagged it with BUG.
The manpage says:
"OCSP_single_get0_status() returns the status of single or -1 if an
error occurred."
With this change, the -1 case is not handled correctly anymore it seems?
I am not sure if it will ever happen, but I have attached a patch for it.

Regards,
Sander

>From 3ed07896ac1f5730dc34900988ae255c7462f8ff Mon Sep 17 00:00:00 2001
From: Sander Hoentjen 
Date: Mon, 23 Oct 2017 10:45:46 +0200
Subject: [PATCH] BUG/MINOR: ssl: catch failure of OCSP_single_get0_status

The manpage says:
"OCSP_single_get0_status() returns the status of single or -1 if an error
occurred." So we must handle -1 as well.
---
 src/ssl_sock.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 7b8570c74..5fb82fd62 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -625,6 +625,10 @@ static int ssl_sock_load_ocsp_response(struct chunk *ocsp_response, struct certi
 		memprintf(err, "OCSP single response: certificate status is unknown");
 		goto out;
 	}
+	else if (rc == -1) {
+		memprintf(err, "OCSP single response: certificate status request failed");
+		goto out;
+	}
 
 	if (!nextupd) {
 		memprintf(err, "OCSP single response: missing nextupdate");
-- 
2.13.6

Re: Is there any best practice for setting tune.bufsize?

2017-10-23 Thread Lukas Tribus 
Hello,


2017-10-23 8:49 GMT+02:00  :
> Hi,
>
> Is there any best practice for setting tune.bufsize?
>
> such as, leave it as is(16k), or never make it bigger than 1MB, something
> like this?

>From the documentation:
> *It is strongly recommended not to change this from the default value*


Best practice is to leave everything as is.


lukas

Is there any best practice for setting tune.bufsize?

2017-10-23 Thread flamesea12 
Hi,

Is there any best practice for setting tune.bufsize?

such as, leave it as is(16k), or never make it bigger than 1MB, something like 
this?

subscribe

2017-10-23 Thread Clement Thomas