Hello,
Thanks for your responses. I will try it that way first. But I think it's more
a workaround than a solution. Both ways are not consistent with the
haproxy-configuration and more error-prone than a scheduling-function in the
software itself would be. In a large environment with a large
I'm not seeing how to use reqrep to alter a POST uri by appending a
'a=1' parameter to the end since there is no support for substitution
groups. Any pointers?
We can't modify the contents of a POST request but we can indeed alter
the URI. And yes it does support substitution groups. For
On Tue, Mar 01, 2011 at 03:30:08PM +0800, Delta Yeh wrote:
Hi Willy,
Do you have any plan to add http compress feature into haproxy ?
Yes, we'll probably implement it here at Exceliance once we're done
with SSL. The internal reworks needed to address SSL are the same as
compression. For a
On Mar 1, 2011, at 12:46 AM, Willy Tarreau wrote:
On Tue, Mar 01, 2011 at 03:30:08PM +0800, Delta Yeh wrote:
Hi Willy,
Do you have any plan to add http compress feature into haproxy ?
Yes, we'll probably implement it here at Exceliance once we're done
with SSL. The internal reworks
Hi Hervé,
Le jeudi 24 février 2011 19:09:06, Hervé COMMOWICK a écrit :
It seems that it miss some things to work correctly. It generates
warnings
Thanks for the feedback, I didn't notice those warnings.
I've applied your updated patch today on haproxy 1.4.11 (in case someone wants
to know if
We have been looking at modifying HAProxy to be able to create ACL's that
read in the request body and forward based upon whether or not a certain
string is contained within it.
It seems like there is everything needed except the acl_fetch_line
function. In this function, we have been able to
Hi Malcolm,
sorry I did not notice your first report.
First, Cyril is right. Weight 0 will never affect persistence and it
is fortunate because weight only applies to LB while persistence is a
way to bypass LB.
On Tue, Mar 01, 2011 at 04:17:30PM +, Malcolm Turnbull wrote:
Cyril et al.
Hi Bryan,
just to keep you updated, I'm pushing the fix into 1.4.12. While fixing
it I discovered that check_post got broken when I implemented client-side
keep-alive, because the content-length we're relying on is reset by the
forwarding code before the LB code is called. So I had to fix that
Hi Nathaniel,
On Tue, Mar 01, 2011 at 11:15:48AM -0800, Nathaniel Irvin wrote:
We have been looking at modifying HAProxy to be able to create ACL's that
read in the request body and forward based upon whether or not a certain
string is contained within it.
It's planned for 1.5 but not done
Thanks for the quick response!
Just a quick correction and question.
When I mentioned requests above 1000k, i actually meant 1000 bytes.
Basically it seemed like it didn't work whenever the request was big enough
to force a 100-Continue. I'm not sure if this would change anything, since
we
On Tue, Mar 01, 2011 at 01:14:21PM -0800, Nathaniel Irvin wrote:
Thanks for the quick response!
Just a quick correction and question.
When I mentioned requests above 1000k, i actually meant 1000 bytes.
Basically it seemed like it didn't work whenever the request was big enough
to force a
Hello,
Can you tell me why HAProxy considers this response from a Riak
backend server invalid? https://gist.github.com/850204
I suspect it's the length of the Link header. Thank you in advance.
-J
It seems like even after I set the flag ANA_REQ_HTTP_BODY, the fetch
function still does not work with the entire message in the buffer. What it
seems like it is getting is just the CRLF in the 100-Continue message. Also
in our fetch function, it seems like the buffer from previous requests is
On Tue, Mar 01, 2011 at 05:39:18PM -0800, Nathaniel Irvin wrote:
It seems like even after I set the flag ANA_REQ_HTTP_BODY, the fetch
function still does not work with the entire message in the buffer.
You should add some markers in the http request body parser to ensure
it is properly called
On Tue, Mar 01, 2011 at 05:24:18PM -0700, Jason J. W. Williams wrote:
Hello,
Can you tell me why HAProxy considers this response from a Riak
backend server invalid? https://gist.github.com/850204
I suspect it's the length of the Link header.
Yes, your header has set a new world record :
Hi Willy,
I figured out it was the line length on the Links header a couple hours ago.
Also explains why my client lib was bombing (put HAProxy in to try and debug).
Fixed it by telling Riak to stream which skips the Links header and chunks
the payload.
Thank you for your help. :) Glad to
16 matches
Mail list logo
