Re: bind keyword
Hi Willy, On 20 June 2012 19:44, Willy Tarreau w...@1wt.eu wrote: Hi Damien, On Wed, Jun 20, 2012 at 04:19:09PM +0100, Damien Churchill wrote: I've found another place where the behaviour appears to diverge from the documentation. At the beginning of section 4 it says that it's mandatory that proxies with overlapping capabilities have different names. My interpretation of that is that frontends can't have the same name, and neither can backends, however a frontend may share a name with a backend, is that correct? I ask as it seems I'm able to (at least with 1.4.18) create multiple instances of front and backends with overlapping names. Config extract: backend some-backend-name balance roundrobin timeout check 1 server localhost 127.0.0.1:80 weight 1 check inter 2000 fall 3 option httpchk HEAD / HTTP/1.1\r\nHost:localhost backend some-backend-name balance roundrobin timeout check 1 server localhost 127.0.0.1:80 weight 1 check inter 2000 fall 3 option httpchk HEAD / HTTP/1.1\r\nHost:localhost frontend test-frontend bind :19001 frontend test-frontend bind :19002 Is this me misinterpreting how things should work or something else going on? Your interpretation is right, but I think you didn't read the warnings that are emitted when starting the service : [WARNING] 171/204356 (2413) : Parsing [overlap.cfg:27]: backend 'some-backend-name' has same name as another backend (declared at overlap.cfg:20). [WARNING] 171/204356 (2413) : Parsing [overlap.cfg:37]: frontend 'test-frontend' has same name as another frontend (declared at overlap.cfg:34). Nothing prevents the config from working, but some features will not reliably work with such a conf (eg: ACLs referencing a backend name). Hence the warning. Okay thanks, it's good to know the expected behaviour. I see the warnings now, I had 'quiet' in the configuration which was suppressing them, my mistake! Thanks, Damien
Response headers max size
Hi List, We are using HAProxy 1.5-dev11 and have a small issue with it. Some of our coders use php firebug when they are debugging code. php firebug puts a lot of stuff in the response headers (X-WF-* headers) But, it looks like HAProxy blocks responses when the headers are larger than 8KB. Is there a way to make HAProxy accept larger response headers? Regards, Sander
Re: Response headers max size
Hi Sander, On Thu, Jun 21, 2012 at 02:06:59PM +0200, Sander Klein wrote: Hi List, We are using HAProxy 1.5-dev11 and have a small issue with it. Some of our coders use php firebug when they are debugging code. php firebug puts a lot of stuff in the response headers (X-WF-* headers) But, it looks like HAProxy blocks responses when the headers are larger than 8KB. Is there a way to make HAProxy accept larger response headers? Yes, you can simply increase the buffer size in the global section : tune.bufsize 16384 to have 16kB for instance. Don't go too high, each connection has two such buffers. Also, keep in mind that such large headers will often be blocked by many intermediaries, so this should not leave your dev lab. Regards, Willy
Haproxy plus ices protocol (99.999% similar to HTTP)
Hello, The ices protocol is based on HTTP and is used for online streaming. In the early days the specification for this protocol was to use 1 GET /serv/login.php?lang=enprofile=2 *ICE*/1.0 2 Host: www.mydomain.com 3 User-agent: my small browser 4 Accept: image/jpeg, image/gif 5 Accept: image/png As you can see, the bolded part is the only difference between this and HTTP. I guess the designer realized this was a bone headed move and almost every modern icecast client today uses HTTP in its request header. However I need it to work for older clients as well. My question is, how can I get haproxy to accept this protocol? option accept-invalid-http-request doesn't seem to be what I want, and I tried using mode tcp until I realized I couldn't because my config file uses use_backend backend if condition (which requires mode http). My config file is fairly simple if this helps: frontend http-in-8001 bind *:8001 acl martin11_master_acl url -i /martin11_master use_backend martin11_master if martin11_master_acl backend martin11_master #mode tcp server martin11_master 192.168.1.147:8002 Martin
Re: Response headers max size
Hi Sander, On Thu, Jun 21, 2012 at 09:06:06PM +0200, Sander Klein wrote: Hi, On 21.06.2012 14:17, Willy Tarreau wrote: Some of our coders use php firebug when they are debugging code. php firebug puts a lot of stuff in the response headers (X-WF-* headers) But, it looks like HAProxy blocks responses when the headers are larger than 8KB. Is there a way to make HAProxy accept larger response headers? Yes, you can simply increase the buffer size in the global section : tune.bufsize 16384 to have 16kB for instance. Don't go too high, each connection has two such buffers. Also, keep in mind that such large headers will often be blocked by many intermediaries, so this should not leave your dev lab. So I noticed, more stuff breaks when you change this :-) Seems like 8K is the way to go. Yes, 8kB often looks like the highest reasonable value. Apache for instance, uses 8kB per line with a max of 101 lines of headers (including the first one). But generally you'll see that you have either an ultra-large URL, or an ultra-large cookie, or a very large number of repeated headers or cookies. So in practice, when you reach 8kB, it's common to see that 90% of these 8kB are on a single line, or that you'll have more than 100 lines. And quite frankly, a request that doesn't pass through the omnipresent Apache is not expected to make a long trip ! Cheers, Willy
Re: Haproxy plus ices protocol (99.999% similar to HTTP)
Hello Martin, On Thu, Jun 21, 2012 at 07:49:13PM -0400, Martin Konecny wrote: Hello, The ices protocol is based on HTTP and is used for online streaming. In the early days the specification for this protocol was to use 1 GET /serv/login.php?lang=enprofile=2 *ICE*/1.0 2 Host: www.mydomain.com 3 User-agent: my small browser 4 Accept: image/jpeg, image/gif 5 Accept: image/png As you can see, the bolded part is the only difference between this and HTTP. I guess the designer realized this was a bone headed move and almost every modern icecast client today uses HTTP in its request header. However I need it to work for older clients as well. My question is, how can I get haproxy to accept this protocol? option accept-invalid-http-request doesn't seem to be what I want, and I tried using mode tcp until I realized I couldn't because my config file uses use_backend backend if condition (which requires mode http). My config file is fairly simple if this helps: frontend http-in-8001 bind *:8001 acl martin11_master_acl url -i /martin11_master use_backend martin11_master if martin11_master_acl backend martin11_master #mode tcp server martin11_master 192.168.1.147:8002 You won't manage to make it pass through in HTTP mode without modifying the code. I have a few other questions, what does the response look like ? Also, does the protocol support content-length, transfer-encoding and content-encoding ? Does it use the same status codes ? Does it support metadata only requests (HEAD) ? Does it support metadata only responses (204, 304) ? Does it support interim responses (100, 101) ? Does it support any form of keep-alive ? Is it compliant to HTTP/1.0 ? To HTTP/1.1 ? All these questions are very important, because the apparent syntax does not make a protocol compatible with HTTP. The semantics are much stronger than that. Regards, Willy
Re: Haproxy plus ices protocol (99.999% similar to HTTP)
Hi Willy, I can only answer your question by saying that other clients that use this protocol but replace ICE/1.0 with HTTP/1.0 have no problem with HAProxy. It seems that those other clients realized it wasn't a good idea to change that part for no good reason :). I thought I had found a solution when I started playing with reqrep (replace ICE with HTTP) but then I noticed only valid HTTP requests were being passed through this operator. Any other ideas? There is no official documentation, but this post http://stackoverflow.com/a/9985297/276949 should give you a brief overview. Martin On Fri, Jun 22, 2012 at 1:37 AM, Willy Tarreau w...@1wt.eu wrote: Hello Martin, On Thu, Jun 21, 2012 at 07:49:13PM -0400, Martin Konecny wrote: Hello, The ices protocol is based on HTTP and is used for online streaming. In the early days the specification for this protocol was to use 1 GET /serv/login.php?lang=enprofile=2 *ICE*/1.0 2 Host: www.mydomain.com 3 User-agent: my small browser 4 Accept: image/jpeg, image/gif 5 Accept: image/png As you can see, the bolded part is the only difference between this and HTTP. I guess the designer realized this was a bone headed move and almost every modern icecast client today uses HTTP in its request header. However I need it to work for older clients as well. My question is, how can I get haproxy to accept this protocol? option accept-invalid-http-request doesn't seem to be what I want, and I tried using mode tcp until I realized I couldn't because my config file uses use_backend backend if condition (which requires mode http). My config file is fairly simple if this helps: frontend http-in-8001 bind *:8001 acl martin11_master_acl url -i /martin11_master use_backend martin11_master if martin11_master_acl backend martin11_master #mode tcp server martin11_master 192.168.1.147:8002 You won't manage to make it pass through in HTTP mode without modifying the code. I have a few other questions, what does the response look like ? Also, does the protocol support content-length, transfer-encoding and content-encoding ? Does it use the same status codes ? Does it support metadata only requests (HEAD) ? Does it support metadata only responses (204, 304) ? Does it support interim responses (100, 101) ? Does it support any form of keep-alive ? Is it compliant to HTTP/1.0 ? To HTTP/1.1 ? All these questions are very important, because the apparent syntax does not make a protocol compatible with HTTP. The semantics are much stronger than that. Regards, Willy
