Re: [ANNOUNCE] haproxy-2.6-dev12
Hi. On Sat, 28 May 2022 11:42:17 + Ajay Mahto wrote: > Unsubscribe me. Feel free to do it by your self. https://www.haproxy.org/#tact Regards Alex > Regards, > > Ajay Kumar Mahto, > Lead DevOps Engineer, > NPCI, Hyderabad > +91 8987510264 > > From: Willy Tarreau > Sent: Friday, May 27, 2022 11:55:07 PM > To: haproxy@formilux.org > Subject: [ANNOUNCE] haproxy-2.6-dev12 > > WARNING: This mail has come from outside. Please verify sender, attachment > and URLs before clicking on them. > > Hi, > > HAProxy 2.6-dev12 was released on 2022/05/27. It added 149 new commits > after version 2.6-dev11. > > Yeah I know, I said we'll only issue -dev12 if we face some trouble. But > stay cool, we didn't face any trouble. However we figured that it would > help last-minute testers to have a final tagged version. > > The vast majority of patches are tagged CLEANUP and MINOR. That's great. > > One old github issue was finally addressed, regarding the HTTP version > validation. In the past we used to accept any 4-letter protocol using > letters H,P,R,S,T, which allowed us to match both HTTP and RTSP. But it > was reported to cause trouble because it was neither possible to disable > RTSP support not extend this to other protocols. The problem with having > RTSP enabled by default is that if haproxy forwards it to a backend server > that doesn't know it, the server may respond with an HTTP/0.9 error that > will be blocked by haproxy which then returns a 502 error. That's no big > deal until you're watching your load balancer's logs and counters. > > So now by default only HTTP is accepted, and this can be relaxed by > adding "accept-invalid-http-request". To be honest, I really doubt that > there are that many people using RTSP, given that we never ever get any > single problem report about it, so I think it will not be a big deal to > add this option in such cases so that all other users gain in serenity. > This will likely be backported but if so, very slowly as this will be a > behavior change, albeit a very small one. > > Some polishing was done on QUIC, to improve the behavior on closing > connections and stopping the process, and error processing in general. > The maintainability was also improved by refactoring certain areas. > Ah, crap, I just noticed that we missed a few patches from Fred who > added some doc and a few settings! > > The conn_streams that were holding up the release are now gone. It took > two of us two full days of code analysis and head scratching to figure > the role of certain antique flags and give them a more appropriate name, > but that was really necessary. I must admit I really like the new model > in 2.6, it's much more consistent and logical than 2.5 and older. It's > visible in that it's easier to document and explain. And even during the > changes it was easier to figure the field names for parts that had to be > changed manually. > > There are a bit more patches than I initially expected because this time > I refused to leave poorly named function arguments and local variables: > we've suffered from this for many years where process_stream() used to > have a "struct stream *sess" and the session was "sess->sess". I didn't > want to experience this anymore, we need the code to be more intuitive > and readable especially for new contributors, and given the large amount > of changes since 2.5 that will complicate backports anyway, it was the > perfect opportunity to pursue that quest. While these changes represent > many patches, they're essentially renames. There's always the tiny risk > of an undetected mistake but all of them are trivial, were reviewed > multiple times, built and individually tested so I'm not worried (famous > last words :-)). > > Some of us will continue testing over the week-end (it's already deployed > on haproxy.org). I think we'll add a few bits of doc, Fred's patches that > we missed, maybe a fix or two for last minute issues, and I expect to > release on Tuesday (because Mondays are usually too short). > > Please find the usual URLs below : >Site index : > https://ind01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haproxy.org%2Fdata=05%7C01%7Cajay.mahto%40npci.org.in%7C9d4ba987a73844dbbef808da400e7c5a%7C8ca9216b1bdf40569775f5e402a48d32%7C0%7C0%7C637892728218046385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=re5z5mdHaKq8gU73DlWwiMCCEYz4E9nnQzamqFlgUeo%3Dreserved=0 > Documentation: > https://ind01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdocs.haproxy.org%2Fdata=05%7C01%7Cajay.mahto%40npci.org.in%7C9d4ba987a73844dbbef8
Re: [ANNOUNCE] haproxy-2.6-dev12
Unsubscribe me. Regards, Ajay Kumar Mahto, Lead DevOps Engineer, NPCI, Hyderabad +91 8987510264 From: Willy Tarreau Sent: Friday, May 27, 2022 11:55:07 PM To: haproxy@formilux.org Subject: [ANNOUNCE] haproxy-2.6-dev12 WARNING: This mail has come from outside. Please verify sender, attachment and URLs before clicking on them. Hi, HAProxy 2.6-dev12 was released on 2022/05/27. It added 149 new commits after version 2.6-dev11. Yeah I know, I said we'll only issue -dev12 if we face some trouble. But stay cool, we didn't face any trouble. However we figured that it would help last-minute testers to have a final tagged version. The vast majority of patches are tagged CLEANUP and MINOR. That's great. One old github issue was finally addressed, regarding the HTTP version validation. In the past we used to accept any 4-letter protocol using letters H,P,R,S,T, which allowed us to match both HTTP and RTSP. But it was reported to cause trouble because it was neither possible to disable RTSP support not extend this to other protocols. The problem with having RTSP enabled by default is that if haproxy forwards it to a backend server that doesn't know it, the server may respond with an HTTP/0.9 error that will be blocked by haproxy which then returns a 502 error. That's no big deal until you're watching your load balancer's logs and counters. So now by default only HTTP is accepted, and this can be relaxed by adding "accept-invalid-http-request". To be honest, I really doubt that there are that many people using RTSP, given that we never ever get any single problem report about it, so I think it will not be a big deal to add this option in such cases so that all other users gain in serenity. This will likely be backported but if so, very slowly as this will be a behavior change, albeit a very small one. Some polishing was done on QUIC, to improve the behavior on closing connections and stopping the process, and error processing in general. The maintainability was also improved by refactoring certain areas. Ah, crap, I just noticed that we missed a few patches from Fred who added some doc and a few settings! The conn_streams that were holding up the release are now gone. It took two of us two full days of code analysis and head scratching to figure the role of certain antique flags and give them a more appropriate name, but that was really necessary. I must admit I really like the new model in 2.6, it's much more consistent and logical than 2.5 and older. It's visible in that it's easier to document and explain. And even during the changes it was easier to figure the field names for parts that had to be changed manually. There are a bit more patches than I initially expected because this time I refused to leave poorly named function arguments and local variables: we've suffered from this for many years where process_stream() used to have a "struct stream *sess" and the session was "sess->sess". I didn't want to experience this anymore, we need the code to be more intuitive and readable especially for new contributors, and given the large amount of changes since 2.5 that will complicate backports anyway, it was the perfect opportunity to pursue that quest. While these changes represent many patches, they're essentially renames. There's always the tiny risk of an undetected mistake but all of them are trivial, were reviewed multiple times, built and individually tested so I'm not worried (famous last words :-)). Some of us will continue testing over the week-end (it's already deployed on haproxy.org). I think we'll add a few bits of doc, Fred's patches that we missed, maybe a fix or two for last minute issues, and I expect to release on Tuesday (because Mondays are usually too short). Please find the usual URLs below : Site index : https://ind01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haproxy.org%2Fdata=05%7C01%7Cajay.mahto%40npci.org.in%7C9d4ba987a73844dbbef808da400e7c5a%7C8ca9216b1bdf40569775f5e402a48d32%7C0%7C0%7C637892728218046385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=re5z5mdHaKq8gU73DlWwiMCCEYz4E9nnQzamqFlgUeo%3Dreserved=0 Documentation: https://ind01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdocs.haproxy.org%2Fdata=05%7C01%7Cajay.mahto%40npci.org.in%7C9d4ba987a73844dbbef808da400e7c5a%7C8ca9216b1bdf40569775f5e402a48d32%7C0%7C0%7C637892728218046385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=PHJsvY2xbGuNCep7m8SKF5ZJ30p67d3vzZIznjxgVoI%3Dreserved=0 Wiki : https://ind01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaproxy%2Fwiki%2Fwikidata=05%7C01%7Cajay.mahto%40npci.org.in%7C9d4ba987a73844dbbef808da400e7c5a%7C8ca9216b1bdf40569775f5e402a48d32%7C0%7C0%7C637892728218046385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
[ANNOUNCE] haproxy-2.6-dev12
Hi, HAProxy 2.6-dev12 was released on 2022/05/27. It added 149 new commits after version 2.6-dev11. Yeah I know, I said we'll only issue -dev12 if we face some trouble. But stay cool, we didn't face any trouble. However we figured that it would help last-minute testers to have a final tagged version. The vast majority of patches are tagged CLEANUP and MINOR. That's great. One old github issue was finally addressed, regarding the HTTP version validation. In the past we used to accept any 4-letter protocol using letters H,P,R,S,T, which allowed us to match both HTTP and RTSP. But it was reported to cause trouble because it was neither possible to disable RTSP support not extend this to other protocols. The problem with having RTSP enabled by default is that if haproxy forwards it to a backend server that doesn't know it, the server may respond with an HTTP/0.9 error that will be blocked by haproxy which then returns a 502 error. That's no big deal until you're watching your load balancer's logs and counters. So now by default only HTTP is accepted, and this can be relaxed by adding "accept-invalid-http-request". To be honest, I really doubt that there are that many people using RTSP, given that we never ever get any single problem report about it, so I think it will not be a big deal to add this option in such cases so that all other users gain in serenity. This will likely be backported but if so, very slowly as this will be a behavior change, albeit a very small one. Some polishing was done on QUIC, to improve the behavior on closing connections and stopping the process, and error processing in general. The maintainability was also improved by refactoring certain areas. Ah, crap, I just noticed that we missed a few patches from Fred who added some doc and a few settings! The conn_streams that were holding up the release are now gone. It took two of us two full days of code analysis and head scratching to figure the role of certain antique flags and give them a more appropriate name, but that was really necessary. I must admit I really like the new model in 2.6, it's much more consistent and logical than 2.5 and older. It's visible in that it's easier to document and explain. And even during the changes it was easier to figure the field names for parts that had to be changed manually. There are a bit more patches than I initially expected because this time I refused to leave poorly named function arguments and local variables: we've suffered from this for many years where process_stream() used to have a "struct stream *sess" and the session was "sess->sess". I didn't want to experience this anymore, we need the code to be more intuitive and readable especially for new contributors, and given the large amount of changes since 2.5 that will complicate backports anyway, it was the perfect opportunity to pursue that quest. While these changes represent many patches, they're essentially renames. There's always the tiny risk of an undetected mistake but all of them are trivial, were reviewed multiple times, built and individually tested so I'm not worried (famous last words :-)). Some of us will continue testing over the week-end (it's already deployed on haproxy.org). I think we'll add a few bits of doc, Fred's patches that we missed, maybe a fix or two for last minute issues, and I expect to release on Tuesday (because Mondays are usually too short). Please find the usual URLs below : Site index : http://www.haproxy.org/ Documentation: http://docs.haproxy.org/ Wiki : https://github.com/haproxy/wiki/wiki Discourse: http://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Sources : http://www.haproxy.org/download/2.6/src/ Git repository : http://git.haproxy.org/git/haproxy.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy.git Changelog: http://www.haproxy.org/download/2.6/src/CHANGELOG Pending bugs : http://www.haproxy.org/l/pending-bugs Reviewed bugs: http://www.haproxy.org/l/reviewed-bugs Code reports : http://www.haproxy.org/l/code-reports Latest builds: http://www.haproxy.org/l/dev-packages Willy --- Complete changelog : Amaury Denoyelle (26): BUG/MEDIUM: mux-quic: adjust buggy proxy closing support Revert "MINOR: quic: activate QUIC traces at compilation" Revert "MINOR: mux-quic: activate qmux traces on stdout via macro" MINOR: h3: mark ncbuf as const on h3_b_dup MINOR: mux-quic: do not alloc quic_stream_desc for uni remote stream MINOR: mux-quic: delay cs_endpoint allocation MINOR: mux-quic: add traces in qc_recv() MINOR: mux-quic: adjust return value of decode_qcs CLEANUP: h3: rename struct h3 -> h3c CLEANUP: h3: rename uni stream type constants BUG/MINOR: h3: prevent overflow when parsing SETTINGS MINOR: h3: refactor
