Re: HTTP/2 Termination vs. Firefox Quantum

Hi Lucas, On Fri, Dec 29, 2017 at 06:06:49AM +, Lucas Rolff wrote: > As much as I agree about that specs should be followed, I realized that even > if there's people that want to follow the spec 100%, there will always be > implementations used in large scale that won't be following the spec 1

Re: HTTP/2 Termination vs. Firefox Quantum

Hi Willy, > In fact it's a race between the GOAWAY frame caused by the invalid request, > and the HEADERS frame being sent in response to the stream being closed > I agree that it's quite confusing, but we're talking about responses to > conditions that are explicitly forbidden in the spec, so I

Re: HTTP/2 Termination vs. Firefox Quantum

Hi Lukas, On Thu, Dec 28, 2017 at 09:19:24PM +0100, Lukas Tribus wrote: > On Thu, Dec 28, 2017 at 12:29 PM, Lukas Tribus wrote: > > Hello, > > > > > >> But in this example, you're using HTTP/1.1, The "Connection" header is > >> perfectly valid for 1.1. It's HTTP/2 which forbids it. There is no >

Re: HTTP/2 Termination vs. Firefox Quantum

Hello, On Thu, Dec 28, 2017 at 10:26 PM, Lucas Rolff wrote: >> the output of the http2 golang test and can you please both clarify which OS >> you reproduce this on? > > If I visit http2 golang test, I also don’t see it, and I saw it in developer > tools (Because dev tools shouldn’t put header

Re: h2 bad requests

Hi Lucas, On 2017-12-28 22:38, Lucas Rolff wrote: Hi Sander, Which exact browser version do you use? There’s an ongoing thread already (https://www.mail-archive.com/haproxy@formilux.org/msg28333.html ) regarding the same issue. I just noticed and was reading up. I can reproduce this problem

Re: h2 bad requests

Hi Sander, Which exact browser version do you use? There’s an ongoing thread already (https://www.mail-archive.com/haproxy@formilux.org/msg28333.html ) regarding the same issue. Best Regards, Lucas Rolff

h2 bad requests

Hi, I'm playing around with http2 on haproxy 1.8.2 but when I enable it I get HTTP 400's on some requests. When sending a show errors to the admin socket I get no errors at all. Disabling http2 makes the rror go away. The logfile shows: Dec 28 22:09:02 hostname haproxy[23043]: x.x.x.x:58219

Re: HTTP/2 Termination vs. Firefox Quantum

> the output of the http2 golang test and can you please both clarify which OS > you reproduce this on? If I visit http2 golang test, I also don’t see it, and I saw it in developer tools (Because dev tools shouldn’t put headers that isn’t requested/received) – however based on your findings, th

Re: HTTP/2 Termination vs. Firefox Quantum

Hello, On Thu, Dec 28, 2017 at 12:29 PM, Lukas Tribus wrote: > Hello, > > >> But in this example, you're using HTTP/1.1, The "Connection" header is >> perfectly valid for 1.1. It's HTTP/2 which forbids it. There is no >> inconsistency here. > > For me a request like this: > $ curl -kv --http2 h

Re: bug: mworker unable to reload on USR2 since baf6ea4b

On Thu, Dec 28, 2017 at 12:54:27AM +0100, William Lallemand wrote: > I think that's better to open /dev/null and dup2 with 0, 1, 2 so we won't > have any > surprise with an fprintf(stderr, ".. anywhere in the code. > Hi, I made a patch which does exactly that, however I think we will do a clea

Re: HAProxy 1.8 takes too long to update new config

hard-stop-after is indeed helping, now it waits for exactly 30s (as configured in the hard-stop-after). Thanks for clarifying. On Thu, Dec 28, 2017 at 11:01 AM Robin Anil wrote: > I see, not only is the command stuck, the stats page does not load beyond > top header part and that state continue

Re: HAProxy 1.8 takes too long to update new config

I see, not only is the command stuck, the stats page does not load beyond top header part and that state continues to persist for about 5-6 minutes. Here is my configuration. defaults log global mode http compression algo gzip compression type text/html text/plain text/css applic

possible bug: no warnings are emitted if server has health-check options but "check" keyword is absent

I just recovered from an outage that was ultimately triggered by HAProxy failing to keep track of the correct IP address for the back-end via periodic DNS queries, despite what appears to have been a correct configuration. Using HAProxy 1.6.13, the backend server configuration entry looks like thi

Re: issue with namesapce for backend

Hello, On Thu, Dec 28, 2017 at 4:18 PM, Andrew Smalley wrote: > > Hi Lukas > > Thank you for the correction. I didn't even think about using CAP_SYS_ADMIN > to give a standard user more privs. > > Out of interest would CAP_NET_BIND_SERVICE not be a better choice than > giving haproxy full adm

Re: issue with namesapce for backend

Hi Lukas Thank you for the correction. I didn't even think about using CAP_SYS_ADMIN to give a standard user more privs. Out of interest would CAP_NET_BIND_SERVICE ​not ​ be a better choice than giving haproxy full admin rights ​, just allow it to bind to ports <1024​ "setcap" - set Linux capa

Re: issue with namesapce for backend

Hello, On 28 December 2017 at 11:24, Senthil Naidu wrote: > > Hi, > > Is there any way to run haproxy as non-root with backend configured inside > the > namespace as seen below but the same shows “general socket error” , if we run > the same by removing the user and group from haproxy and run

Re: HTTP/2 Termination vs. Firefox Quantum

Hello, > But in this example, you're using HTTP/1.1, The "Connection" header is > perfectly valid for 1.1. It's HTTP/2 which forbids it. There is no > inconsistency here. For me a request like this: $ curl -kv --http2 https://localhost/111 -H "Connection: keep-alive" -d "bla=bla" Fired multiple

Re: issue with namesapce for backend

Hello Senthil You asked if you can run haproxy as a non root user. Yes you can but only for ports above 1024, ports below 1024 and port 80 as per your config will require root privileges to bind to the port. Andruw Smalley Loadbalancer.org Ltd. www.loadbalancer.org

Re: HTTP/2 Termination vs. Firefox Quantum

>Did I get it right, according to the spec, the "Connection"-header is > forbidden ("MUST NOT"), still, firefox does send it? This leads to the > described issue. I think it indeed might be the root cause, also for failed GET requests (which only seems to happen sometimes?) but it’s really

issue with namesapce for backend

Hi, Is there any way to run haproxy as non-root with backend configured inside the namespace as seen below but the same shows “general socket error” , if we run the same by removing the user and group from haproxy and run the same as root the the same works fine. Regards Senthil global max

AW: HTTP/2 Termination vs. Firefox Quantum

Sorry, for my long absence. Thank you, Lucas, for perfectly describing and digging into the issue. I'll be here if there is any further assistance required. Did I get it right, according to the spec, the "Connection"-header is forbidden ("MUST NOT"), still, firefox does send it? This leads to

Re: HTTP/2 Termination vs. Firefox Quantum

Sorry regarding my previous curl – I didn’t use --http2 in my curl request, but result is the same (with negotiated http2 protocol), I’ve removed the TLSv1.2 output since it’s useless in this case: === $ curl 'https://dashboard.domain.com/js/app.js?v=1' -H 'User-

Re: HTTP/2 Termination vs. Firefox Quantum

On Thu, Dec 28, 2017 at 10:27:28AM +, Lucas Rolff wrote: > In that case, haproxy should be consistent in it's way of handling clients > sending connection-specific headers: > > $ curl 'https://dashboard.domain.com/js/app.js?v=1' -H 'User-Agent: > Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13;

Re: HTTP/2 Termination vs. Firefox Quantum

> It's normal then, as it's mandated by the HTTP/2 spec to reject requests > containing any connection-specific header fields In that case, haproxy should be consistent in it’s way of handling clients sending connection-specific headers: $ curl 'https://dashboard.domain.com/js/app.js?v=1' -H '

Re: HAProxy 1.8 takes too long to update new config

Hello, > I'm sorry but I don't understand what you call "this" above nor what you > mean by "updating the config". > > If the server is running in http2 mode, and servicing connections, updating > the config as shown below is no longer instantaneous. Takes over 5 minutes. So what you are saying

Re: HAProxy 1.8 takes too long to update new config

On Thu, Dec 28, 2017 at 03:41:51AM -0600, Robin Anil wrote: > If the server is running in http2 mode, and servicing connections, updating > the config as shown below is no longer instantaneous. Takes over 5 minutes. > Even when the update is a no-op like adding a new line at the end of the > existi

Re: HAProxy 1.8 takes too long to update new config

- from a phone, xquz typoz On Dec 28, 2017 3:31 AM, "Willy Tarreau" wrote: Hi Robert, On Thu, Dec 28, 2017 at 07:47:03AM +, Robin Anil wrote: > In Http/2 mode with threads enabled, updating the config on a live serving > haproxy server takes several minutes. > > If I turn this off, the upda

Re: HAProxy 1.8 takes too long to update new config

Hi Robert, On Thu, Dec 28, 2017 at 07:47:03AM +, Robin Anil wrote: > In Http/2 mode with threads enabled, updating the config on a live serving > haproxy server takes several minutes. > > If I turn this off, the update of config is near instantaneous. I'm sorry but I don't understand what yo

Re: HTTP/2 Termination vs. Firefox Quantum

Hi Lucas, On Thu, Dec 28, 2017 at 08:38:52AM +, Lucas Rolff wrote: > It worked as it should, so I started adding more and more headers, until I > hit the culprit: -H "Connection: keep-alive" or -H "Connection: close" (or > even "Connection: test") (...) It's normal then, as it's mandated by

Re: haproxy 1.8.2 ALPN h2 broken?

On Wed, Dec 27, 2017 at 07:30:29PM +, Lucas Rolff wrote: > > Could you please just remove this option (or replace it with > > http-server-close if you absolutely want to disable keepalive for any > > reason) ? > > I can't remember why I disabled keep-alive, however - removing it completely

Re: HAProxy 1.8 takes too long to update new config

I just saw. since I don't know how to add to a thread which I am not part of (I still haven't subscribed to the haproxy mailing list). I will have to indicate here that the issue I am having is not in firefox but on the latest chrome stable. I can consistently make it happen in our discourse insta

Re: HAProxy 1.8 takes too long to update new config

Robin, there's also an ongoing thread with Firefox which has the same issues, especially with post/put requests in 1.8.2, you might wanna keep an eye on that one as well Get Outlook for iOS From: Robin Anil Sent: Thursday, December 28, 201

Re: HTTP/2 Termination vs. Firefox Quantum

I think I might have found a cause for this to happen, or at least a way to fully replicate the issue I saw that the issue also happens in Firefox whenever doing POST requests (Let’s say, logging into a website) – I got a bunch of “400 Bad Request” whenever trying to actually do the post reques

Re: HAProxy 1.8 takes too long to update new config

I can isolate that to http2, not threads at v1.8.2 Separately, I am seeing a lot of intermittent failures with POST/PUT requests, I see the following returned from haproxy. 400 Bad request Your browser sent an invalid request. I can verify these requests never hit the backend. On Thu, Dec