Re: STATUS and Backport Review efficiency
On 6/8/15 10:17 AM, William A Rowe Jr wrote: > In this example, the patch was enhanced and the original reviewers' efforts > were thrown away. It's a shame to waste the limited review cycles. > > Moving forwards, can we please do two things. 1) retain the original patch > and > vote in the STATUS, adding a revised patch below the vote that can be > reviewed, > and 2) show the changelog of patch 1 vs. patch 2 so that the original reviewer > doesn't have to bisect two patches to determine whether the change had any > measurable effect on the original patch review? > > We might start an > http://svn.apache.org/repos/asf/httpd/httpd/patches/backports/2.[24].x/ tree, > so that viewvc can be helpful in this respect, instead of multiple patches > residing in our individual public_html/ trees. WDYAT? > > All of this is to say that we should pay extra close attention to correctness > when we first submit a backport patch proposal, and request 3) is to please > not > use STATUS as a discussion tool. If the comment/observation doesn't fit in > 240 > characters (3 lines), it probably belongs on the list instead, or can be a > short note in STATUS with a long explanation on dev. This would be a lot less painful if the httpd project would actually use SVN for managing these patches. The the SVN project does this. Here's an example of a SVN STATUS entry (from the 1.8.x release branch): [[[ * r1654932, r1654933, r1654934, r1654937 Fix issue #4554, "0 file length reported in FSFS". Justification: This causes 'svnadmin dump' to create corrupted output that fails to load and we provide no way to detect that problem other than loading the respective dump. We also want to prevent further instances of that issue to be added to the repository. Notes: r1561419 has been removed from this change set and proposed for a separate backport because it is not a necessary part of the #4554 fix. Branch: ^/subversion/branches/1.8.x-issue4554-v2 Votes: +1: rhuijben +1: stefan2 (before -v2 branch) +0: danielsh (hard to review all potential causes of expanded_size==0 in 7*3*2 cases (1.1…1.8) × (file/dir/prop rep) × (plain/delta)) ]]] The first line is the trunk revisions being backported. However, these changes do not cleanly merge from trunk onto 1.8.x. So a backport branch was made. The change was merged and any conflicts resolved (or possibly other changes). This particular change is a tad unusual in that a second backport branch was made. Usually any modifications just mean additional changes on the branch and the vote split would notice which branch changes weren't included in the review. The workflow for the httpd project would look something like this (presuming you start with the 2.4.x branch checked out in your $PWD): svn cp ^/httpd/httpd/branches/2.4.x ^/httpd/httpd/branches/2.4.x-ap-listeners-buckets svn switch ^/httpd/httpd/branches/2.4.x-ap-listeners-buckets svn merge -c 'r1640763, r1643179, r1656368' ^/httpd/httpd/trunk . # handle conflicts or anything needed. svn ci # Further changes repeat the merge/commit. svn switch ^/httpd/httpd/branches/2.4.x Then when approved you merge the branch onto the release branch like so onto the 2.4.x branch (presuming you start with 2.4.x branch checked out in your $PWD): svn merge ^/httpd/httpd/branches/2.4.x-ap-listeners-buckets . svn rm ^/httpd/httpd/branches/2.4.x-ap-listeners-buckets Using this workflow resolves almost all of your requests. 1) You can preserve votes easily by noting when someone didn't vote for new revisions on the branch and moving their vote to a separate line. 2) You have history, no need to try and track the history in the STATUS file. 3) This doesn't resolve this issue and the SVN project somewhat does the same as you can see above. But I think it helps because it's far less confusing about what everyone reviewed and what their comments are about.
Review of 2.2.x security patch sought.
Committers, we ended up short on reviewers in the security list, and are proceeding shortly with 2.4.14. I can't proceed with 2.2.30 until I get a third set of eyeballs on the 2.2.30-dev backport, could someone offer to review ASAP? I will be tagging once the backport is approved, no other changes to 2.2.x. branch until 2.2.31-dev. The defect is considered Low severity based on httpd team's initial assessment. The other patch coming in a moment doesn't apply to 2.2.x at all. On Tue, Jun 9, 2015 at 3:26 PM, wrote: > Adjust URL for public consumption > > Modified: > httpd/httpd/branches/2.2.x/STATUS > > Modified: httpd/httpd/branches/2.2.x/STATUS > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=1684520&r1=1684519&r2=1684520&view=diff > > == > --- httpd/httpd/branches/2.2.x/STATUS (original) > +++ httpd/httpd/branches/2.2.x/STATUS Tue Jun 9 20:26:47 2015 > @@ -109,12 +109,12 @@ RELEASE SHOWSTOPPERS: >Reported by: Régis Leroy > >trunk > +http://svn.apache.org/r1484852 > +http://svn.apache.org/r1684513 >2.4.x branch > +http://svn.apache.org/r1684515 >2.2.x branch > + > http://people.apache.org/~wrowe/httpd-2.2.x-ap_http_filter-chunked-v6.patch >+1: ylavic, wrowe >jim notes: test framework errors due to 413->400 error change [test > adjusted] > > > >
Apache-Test pre-requisites
My apologies for asking - but I am sure there are extra perl mods that need to be installed before Apache-Test will operate as expected. Unfortunately, it does not seem to demand them, and I have forgotten the extra mods I loaded to get 100's of tests compared to the 13 I am getting now. I had hoped CPAN would tell me, but unfortunately, no. cpan> install Apache::Test CPAN: Storable loaded ok Fetching with LWP: ftp://download.xs4all.nl/pub/mirror/CPAN/authors/01mailrc.txt.gz Going to read /var/perl/.cpan/sources/authors/01mailrc.txt.gz Fetching with LWP: ftp://download.xs4all.nl/pub/mirror/CPAN/modules/02packages.details.txt.gz Going to read /var/perl/.cpan/sources/modules/02packages.details.txt.gz Database was generated on Tue, 09 Jun 2015 17:17:02 GMT There's a new CPAN.pm version (v2.10) available! [Current version is v1.7601] You might want to try install Bundle::CPAN reload cpan without quitting the current session. It should be a seamless upgrade while we are running... Fetching with LWP: ftp://download.xs4all.nl/pub/mirror/CPAN/modules/03modlist.data.gz Going to read /var/perl/.cpan/sources/modules/03modlist.data.gz Going to write /var/perl/.cpan/Metadata Apache::Test is up to date. Reminders are welcome! Michael Tests are ending with: Failed 2/13 test scripts, 84.62% okay. 7/43 subtests failed, 83.72% okay. whereas before I was gettign numbers such as: Failed 18/109 test programs. 247/4555 subtests failed. And I have also had all test successful... But do not have those saved. Mainly I am looking at 2/13 and 7/43 compared to 18/109 and 247/4555
Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI
> On Jun 9, 2015, at 3:42 AM, Yann Ylavic wrote: > > It just needed to get out :) > > But I agree that since we are to implement the RFC, we must comply, > and find a way to still comply with HTTP/1. > Both checks on SNI and renegotiation occur in the post_read_request > hook, so we should be able to deal with vhost's parameters (configured > Protocols, ProtocolTransports...), and do the right thing. > > On Tue, Jun 9, 2015 at 12:09 PM, Stefan Eissing > wrote: >> Yann, I am with you and feel at least unease about this mixing. >> >> But the RFC has been approved and browsers will adhere to it. So if we do >> not enforce some policies in the server, connections will fail for >> mysterious reasons. And tickets will be raised... Well, don't be too hasty. There are a number of requirements in the RFC that have nothing to do with HTTP and should be summarily ignored in the core implementation. There are other requirements in the RFC that might turn out to be wrong or unnecessary, just as we found in RFC2068, and it is our task to implement what works and change the RFCs later. However, the server as a whole should be configurable to be compliant (by default) in the relevant code. All of the requirements around TLS, for example, need to be available in the SSL configs, but it is not h2's responsibility to ensure that it has an RFC7540-compliant TLS config. That is the admin's responsibility/choice. WRT renegotiation, it is fair to say that the WG punted on the idea due to lack of time. If someone figures out a way to safely renegotiate an h2 connection (and all of its streams), then go ahead and implement it, describe it in an I-D, and submit it to the httpbis WG. There is nothing wrong with Apache leading by example. Cheers, Roy
Re: svn commit: r1684457 - /httpd/httpd/branches/2.2.x/STATUS
On Tue, Jun 9, 2015 at 5:46 PM, William A Rowe Jr wrote: > I don't entirely understand the patch CHANGES, however... > > On Tue, Jun 9, 2015 at 10:41 AM, wrote: >> >> PATCHES ACCEPTED TO BACKPORT FROM TRUNK: >>[ start all new proposals below, under PATCHES PROPOSED. ] >> >> * mod_ssl: bring SNI behavior into better conformance with RFC 6066 >> (also addresses PR 56241) >> trunk patch: https://svn.apache.org/r1585090 >>(partial, w/o startup warnings changes) >> 2.4.x patch: https://svn.apache.org/r1588424 >>(backported to 2.4.10) >> 2.2.x patch: >> http://people.apache.org/~ylavic/httpd-2.2.x-no_sni_warning.patch >> + +1: ylavic, jorton, wrowe > > > The patch claims both adjusting alerts and changing startup behavior... The CHANGES entry is, but not the patch (and STATUS entry), as per: >> trunk patch: https://svn.apache.org/r1585090 >>(partial, w/o startup warnings changes) above. > > Everything else is commentary. When you backport, Yann, would you correct > the message? Done in r1684462. Thanks for noticing.
Re: svn commit: r1684457 - /httpd/httpd/branches/2.2.x/STATUS
I don't entirely understand the patch CHANGES, however... On Tue, Jun 9, 2015 at 10:41 AM, wrote: > PATCHES ACCEPTED TO BACKPORT FROM TRUNK: >[ start all new proposals below, under PATCHES PROPOSED. ] > > * mod_ssl: bring SNI behavior into better conformance with RFC 6066 > (also addresses PR 56241) > trunk patch: https://svn.apache.org/r1585090 >(partial, w/o startup warnings changes) > 2.4.x patch: https://svn.apache.org/r1588424 >(backported to 2.4.10) > 2.2.x patch: > http://people.apache.org/~ylavic/httpd-2.2.x-no_sni_warning.patch > + +1: ylavic, jorton, wrowe > The patch claims both adjusting alerts and changing startup behavior... --- CHANGES (revision 1684331) +++ CHANGES (working copy) @@ -1,6 +1,11 @@ -*- coding: utf-8 -*- Changes with Apache 2.2.30 + *) mod_ssl: bring SNI behavior into better conformance with RFC 6066: + no longer send warning-level unrecognized_name(112) alerts, + and limit startup warnings to cases where an OpenSSL version + without TLS extension support is used. PR 56241. [Kaspar Brand] + *) http: Make ap_die() robust against any HTTP error code and not modify response status (finally logged) when nothing is to be done. [Yann Ylavic] But the patch contains only the first change to code. @@ -1962,7 +1962,21 @@ int ssl_callback_ServerNameIndication(SSL *ssl, in "No matching SSL virtual host for servername " "%s found (using default/first virtual host)", servername); -return SSL_TLSEXT_ERR_ALERT_WARNING; Everything else is commentary. When you backport, Yann, would you correct the message?
Re: thread/mpm advice
Graham and Jim, thanks for the advice. As to prefork: as long as APR has threads and mutex and all these fine things, I am pretty certain the mod_h2 itself does not have a problem with prefork. The concern I have is: if people use prefork to have code running which is not thread-safe, that will not make it safe in mod_h2. Or if people use prefork as an indication to avoid mutex and other sync helpers, they will be surprised. I am just adding a WARNING log on startup (once) that says that mod_h2 in prefork might be a source of unpleasant surprises. But I leave mod_h2 running. //Stefan > Am 09.06.2015 um 17:04 schrieb Graham Leggett : > > On 09 Jun 2015, at 3:37 PM, Stefan Eissing > wrote: > >> My understanding is that one uses mpm_prefork when threads are to be >> avoided. This is not what mod_h2 is about and so I consider disabling the >> module in a prefork configuration. My thinking: if threads are not a >> problem, why not run worker/event? > > Getting prefork to work would be a good thing. > > The prefork MPM is the “tank” MPM - regardless of what the client does, > regardless of what code is being spawned by httpd, any leak/crash affects > that connection only. > > mod_h2 might not be fully featured or fully performant under prefork, but > that’s fine in theory. > > Regards, > Graham > — > bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: thread/mpm advice
On 09 Jun 2015, at 3:37 PM, Stefan Eissing wrote: > My understanding is that one uses mpm_prefork when threads are to be avoided. > This is not what mod_h2 is about and so I consider disabling the module in a > prefork configuration. My thinking: if threads are not a problem, why not run > worker/event? Getting prefork to work would be a good thing. The prefork MPM is the “tank” MPM - regardless of what the client does, regardless of what code is being spawned by httpd, any leak/crash affects that connection only. mod_h2 might not be fully featured or fully performant under prefork, but that’s fine in theory. Regards, Graham —
Re: thread/mpm advice
Prefork is the only (unix) MPM which is non-threaded. > On Jun 9, 2015, at 9:37 AM, Stefan Eissing > wrote: > > Hi Knowledgeable List! > > someone reported issues with mod_h2 in relation to some mod_proxy/mod_rewrite > setup of his. I added several test cases and all seems fine. Then I found out > that he is running on a mpm_prefork configuration... > > My understanding is that one uses mpm_prefork when threads are to be avoided. > This is not what mod_h2 is about and so I consider disabling the module in a > prefork configuration. My thinking: if threads are not a problem, why not run > worker/event? > > Do you have any advice for mod_h2 here? Are there other mpms where the module > should disable itself? > > Thanks for the help, > > Stefan > > bytes GmbH > Hafenweg 16, 48155 Münster, Germany > Phone: +49 251 2807760. Amtsgericht Münster: HRB5782 > > >
thread/mpm advice
Hi Knowledgeable List! someone reported issues with mod_h2 in relation to some mod_proxy/mod_rewrite setup of his. I added several test cases and all seems fine. Then I found out that he is running on a mpm_prefork configuration... My understanding is that one uses mpm_prefork when threads are to be avoided. This is not what mod_h2 is about and so I consider disabling the module in a prefork configuration. My thinking: if threads are not a problem, why not run worker/event? Do you have any advice for mod_h2 here? Are there other mpms where the module should disable itself? Thanks for the help, Stefan bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI
It just needed to get out :) But I agree that since we are to implement the RFC, we must comply, and find a way to still comply with HTTP/1. Both checks on SNI and renegotiation occur in the post_read_request hook, so we should be able to deal with vhost's parameters (configured Protocols, ProtocolTransports...), and do the right thing. On Tue, Jun 9, 2015 at 12:09 PM, Stefan Eissing wrote: > Yann, I am with you and feel at least unease about this mixing. > > But the RFC has been approved and browsers will adhere to it. So if we do not > enforce some policies in the server, connections will fail for mysterious > reasons. And tickets will be raised... > > >> Am 09.06.2015 um 12:06 schrieb Yann Ylavic : >> >> On Tue, Jun 9, 2015 at 11:21 AM, Stefan Eissing >> wrote: >>> >>> Also from RFC 7540, 9.2.1 >>> "A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation.“ >>> >>> (Once the h2 session is established, renegotiation may appear before that.) >>> >>> This is all a result of the „securing the web“ thinking where now HTTP and >>> TLS requirements get interwoven and layers are mixed. >> >> >> Security by mixing layers, how ironic! >> Surely HTTP/2 will secure those who want to share private and valuable >> informations (secretly), as to the web... >> It could have been that, though. >> >> >> PS: nothing personal Stefan, just about the new protocol I'm trying to >> digest... > > bytes GmbH > Hafenweg 16, 48155 Münster, Germany > Phone: +49 251 2807760. Amtsgericht Münster: HRB5782 > > >
Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI
Yann, I am with you and feel at least unease about this mixing. But the RFC has been approved and browsers will adhere to it. So if we do not enforce some policies in the server, connections will fail for mysterious reasons. And tickets will be raised... > Am 09.06.2015 um 12:06 schrieb Yann Ylavic : > > On Tue, Jun 9, 2015 at 11:21 AM, Stefan Eissing > wrote: >> >> Also from RFC 7540, 9.2.1 >> "A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation.“ >> >> (Once the h2 session is established, renegotiation may appear before that.) >> >> This is all a result of the „securing the web“ thinking where now HTTP and >> TLS requirements get interwoven and layers are mixed. > > > Security by mixing layers, how ironic! > Surely HTTP/2 will secure those who want to share private and valuable > informations (secretly), as to the web... > It could have been that, though. > > > PS: nothing personal Stefan, just about the new protocol I'm trying to > digest... bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI
On Tue, Jun 9, 2015 at 11:21 AM, Stefan Eissing wrote: > > Also from RFC 7540, 9.2.1 > "A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation.“ > > (Once the h2 session is established, renegotiation may appear before that.) > > This is all a result of the „securing the web“ thinking where now HTTP and > TLS requirements get interwoven and layers are mixed. Security by mixing layers, how ironic! Surely HTTP/2 will secure those who want to share private and valuable informations (secretly), as to the web... It could have been that, though. PS: nothing personal Stefan, just about the new protocol I'm trying to digest...
Re: RFC 7540 (HTTP/2) wrt reusable connections and SNI
Btw. I have the first report from a user that gets 400 answers in browsers when mod_h2 is active because the browser reused the connection for another host. Also from RFC 7540, 9.2.1 "A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation.“ (Once the h2 session is established, renegotiation may appear before that.) This is all a result of the „securing the web“ thinking where now HTTP and TLS requirements get interwoven and layers are mixed. Which means for httpd that mod_ssl and mod_h2 need to talk to each other more. So, when a vhost allows all kinds of renegotiations / parameters, that should be fine and continue being useful when the connection talks HTTP/1. But when h2 is active, some sort of policy restriction needs to be applied (to make it fully standard compliant). Any ideas how to tackle this are appreciated. > Am 08.06.2015 um 15:56 schrieb Eric Covener : > > What's the point of SNI if it can be used to select the correct vhost > before the handshake (modulo the port...), but TLS must possibly be > renegotiated later for subsequent requests? > > In configs that use separate certificates, it gets you the correct one, and > these are n/a to the coalescing problem > > In configs that use the same certificate, I guess it gets you slightly > different TLS parameters. If you use HTTP/2, you'll have to forego these and > per-dir renegotiations. > > Maybe the latter should just be deprecated, it seems like they cause constant > problems > > bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
