Hello David,
On Sun, Jun 28, 2015 at 01:33:49PM +0100, David CARLIER wrote:
Here there are new patchiest with both versions whichever suits the best
can be picked up.
Thanks for your patches. Note that you sent two different versions of
patch 2.
I have a few questions here :
1) I used to
Hi Charlie,
On Mon, Jun 29, 2015 at 05:03:00PM +0100, Charlie Smurthwaite wrote:
Hi,
I am using haproxy to proxy SVN connections. The process works as follows:
* The SVN client opens a TCP connection and sends multiple pipelined GET
requests
* HAProxy opens a connection to a backend for
Hi Dragan,
On Mon, Jun 29, 2015 at 04:43:24PM +0200, Dragan Dosen wrote:
Hi,
I'm sending you three patches for 51Degrees converter.
Dragan Dosen (3):
MEDIUM: 51Degrees code refactoring and cleanup
MEDIUM: 51d: add LRU-based cache on User-Agent string detection
DOC: add notes about
DearSir/Madam, Goodday!
ThisisNinefromYMCoinChina.WespecializedinCharger/S=witch/LEDlightsfor14years,withthecustomersofToshiba,Whelene=tc.,andhopetofindawaytocooperatewithyou!
Allofourproductswillbetestedonebyonebeforeshipping=.
On 30/06/15 12:50, Charlie Smurthwaite wrote:
Hi Willy,
Please find attached a tgz containing the following:
* Output from strace -o log -tts 16384 -p $(haproxy_pid)
* Full packet capture of all port-80 traffic (client is on 10.0.2.82)
* Log output from client identifying corrupt file
*
Hi Holger,
tcp-response content track- / http-response track- would be a nice
feature, don't know if this is on the roadmap.
For the moment i can only imagine the following (needs HAProxy 1.6):
http-response lua script.lua
Within this Lua function, you check the http response code and
On Tue, Jun 30, 2015 at 01:17:03PM +0100, Charlie Smurthwaite wrote:
On 30/06/15 12:50, Charlie Smurthwaite wrote:
Hi Willy,
Please find attached a tgz containing the following:
* Output from strace -o log -tts 16384 -p $(haproxy_pid)
* Full packet capture of all port-80 traffic (client
Hello all,
Unfortunately, I have not received any feedback on my earlier email so
I'll try again.
I am still struggling trying to implement a throttling mechanism based
on prior HTTP responses of the same client.
Basically, I have some requests (using Basic Auth or other mechanisms)
that might
On 30/06/15 13:37, Willy Tarreau wrote:
(...)
12:37:57.056999 sendto(3,
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
(...)
0\0\0\0\0\0\0\0\0\0\0\0,
2967, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE, NULL, 0) = 2967
Huh?
We find it here, pretty easily this time thanks to the long series
Hi Charlie,
On Tue, Jun 30, 2015 at 10:24:44AM +0100, Charlie Smurthwaite wrote:
Hi Willy,
Thanks for getting back to me.
I have not tried this with many versions. I initially observed this in
1.5.9, and then upgraded to 1.5.12. So far I have only observed this in
my production setup
Hi Willy,
Thanks for getting back to me.
I have not tried this with many versions. I initially observed this in
1.5.9, and then upgraded to 1.5.12. So far I have only observed this in
my production setup and have not had an opportunity to reproduce it in a
lab environment.
This seems to
On 30/06/15 11:47, Willy Tarreau wrote:
What causes a problem to me is that haproxy doesn't decide how/where
the packets are segmented, the TCP stack does it. This does not mean
haproxy is not faulty, but that it had 1288 valid positions to cut
these data and that by pure luck it cut them on
12 matches
Mail list logo
