Need more info on compression

2012-11-22 Thread Dmitry Sivachenko
Hello!

I was reading docs about HTTP compression support in -dev13 and it is a bit
unclear to me how it works.

Imagine I have:
compression algo gzip
compression type text/html text/javascript text/xml text/plain

in defaults section.

What will haproxy do if:
1) backend server does NOT support compression;
2) backend server does support compression;
3) backend server does support compression and there is no these two
compression* lines in haproxy config.

I think documentation needs to clarify things a bit.

In return, I am attaching a small patch which fixes 2 typos.

Thanks!
--- configuration.txt.orig  2012-11-22 04:11:33.0 +0400
+++ configuration.txt   2012-11-22 19:58:46.0 +0400
@@ -1887,7 +1887,7 @@
 offload  makes haproxy work as a compression offloader only (see notes).
 
   The currently supported algorithms are :
-identity  this is mostly for debugging, and it was useful for developping
+identity  this is mostly for debugging, and it was useful for developing
   the compression feature. Identity does not apply any change on
   data.
 
@@ -1901,7 +1901,7 @@
   This setting is only available when support for zlib was built
   in.
 
-  Compression will be activated depending of the Accept-Encoding request
+  Compression will be activated depending on the Accept-Encoding request
   header. With identity, it does not take care of that header.
 
   The offload setting makes haproxy remove the Accept-Encoding header to


Re: -dev13 dumps core on reload

2012-11-22 Thread Willy Tarreau
Hello Dmitry,

On Fri, Nov 23, 2012 at 10:01:46AM +0400, Dmitry Sivachenko wrote:
 Hello!
 
 Every time I do graceful restart (haproxy -sf oldpid) for -dev13
 old process dumps core:

Very interesting. I have only observed a 100% CPU loop for a few seconds
but not the core.

 Core was generated by `haproxy'.
 Program terminated with signal 11, Segmentation fault.
 #0  0x000801567d8c in free () from /lib/libc.so.7
 [New Thread 801c07400 (LWP 205381/haproxy)]
 (gdb) bt
 #0  0x000801567d8c in free () from /lib/libc.so.7
 #1  0x00406f64 in deinit () at src/haproxy.c:1108

OK, looks like a double free during deinit. Quite frankly I'm really
bored by this deinit thing. We did this to please valgrind users who
complained that valgrind estimated there were memory leaks, and since
the day we introduced this thing, things got worse and we even caused
segfaults at runtime due to the way we have to manage incomplete structs
upon config errors. I'd really be tempted to definitely remove this
crap and ignore valgrind complaints. It's really a sham when using such
a tool induces bugs in the code as side effects :-(

 #2  0x004078c7 in main (argc=Variable argc is not available.
 ) at src/haproxy.c:1519
 (gdb)
 
 
 I observe this with several different configs so i think it should be easy to
 reproduce.  I can send coredump+config if necessary.

I'd be interested in knowing if your config enables compression, because
that's an area where we very recently introduced new pools, so there could
be a relation.

Thanks!
Willy