Re: TIL
> Am 26.04.2016 um 23:57 schrieb Yann Ylavic : > > On Tue, Apr 26, 2016 at 4:49 PM, Stefan Eissing > wrote: >> Today I Learned the difference between writing >> DATA + META >> and >> DATA + META + FLUSH >> to the core output filters. I am astonished that >> my code ever worked. >> >> Seriously, what is the reason for this kind of >> implementation? > > Do you mean why META could be destroyed before (setaside-)DATA, in > remove_empty_buckets()? Yes. That was unexpected. My understanding of the pass_brigade contract was that buckets get destroyed in order of appearance (might be after the call). > >> I would like to pass META buckets >> in non-blocking way and *not* lose the order of >> bucket destruction. Any explanation or advice is >> appreciated! > > You'd want to setaside (some) META buckets with DATA (in order), right? > At least for EOR buckets, that would keep requests in memory longer > than necessary, but maybe some other META are worth it... It's all fine if users of the filters can be aware of what the conditions and rules are. It is part of the API for all modules that pass buckets through the filters. The h2 use case is to pass a meta bucket that, when destroyed, signals the end of life for data belonging to one stream. So all buckets before that one should have been either destroyed or setaside already. With http/1.x and EOR, my current reading of the code, this does not happen since EORs are always FLUSHed. And even if, releasing the request pool early will probably go unnoticed as WRITE_COMPLETION will read all memory *before* a new pool is opened on the conn pool. This (again, if my reading is correct) does no longer hold in h2. request (stream) starting and ending is happening all the time, conn child pools are created/destroyed all the time. What I saw was memory nullified, by assumedly, new apr_pcallocs, that should not have been freed already. With more likelihood the more load and the less logging, of course. -Stefan
Re: svn commit: r1739876 - /httpd/httpd/branches/2.4.x/STATUS
> Am 27.04.2016 um 03:53 schrieb William A Rowe Jr : > > > My gut instinct is to propose scoreboard.c for a full svn revert back > to a working state, I did not realize that it is that deep of a mess now. Please revert, uncomment the new calls use in http2 and I'll find another approach there. It seems that there are a lot of expectations on how this part of the server behaves, but no way to verify any changes/additions against them for a newbie like me. Since this whole h2 thing is experimental and needs to evolve based on user feedback, it better either use the extension possibilities of mod_status or come up with a new, separate approach that allows frequent changes. -Stefan
Re: svn commit: r1739876 - /httpd/httpd/branches/2.4.x/STATUS
On Tue, Apr 26, 2016 at 5:01 PM, Yann Ylavic wrote: > On Tue, Apr 26, 2016 at 10:48 PM, William A Rowe Jr > wrote: > > On Tue, Apr 26, 2016 at 3:47 PM, William A Rowe Jr > > wrote: > >> > >> Reviewing the applicable patch, the client, request and protocol now > >> appear > > > > ... the client, vhost and protocol now appear ... > > > >> to persist for idle connections, but the request is still NULL? > >> > >> Is this by design? Or is something missing from the patch? > > Is it different behaviour than 2.4.18 (it shouldn't)? > > We are discussing different issues/solutions in PR 59333... > AIUI the previous behavior was to retain the prior request until the new keep-alive request began processing the post-read-request phase, until that point the previous request on that pipeline should still appear in the connection's status. I'm now already following that thread since this afternoon and have to compare notes against 2.4.17-.18-.20-post-patch behaviors. My gut instinct is to propose scoreboard.c for a full svn revert back to a working state, but will help if folks demonstrate some effort toward preserving ABI and functional state compatibility... at least over the next few days. Cheers, Bill
Re: Recent updates to httpd-trunk
Thanks, done in r1741112 and r1741115. Regards, Yann.
Recent updates to httpd-trunk
G/M from a very warm autumn. 1. Could someone please: - set the correct EOL type in svn for .\modules\http2\NWGNUproxyht2, - Patch as per the following to allow builds of \http2 and \ssl D:\Projects\svn\httpd-trunk>svn diff Index: modules/http2/NWGNUmod_http2 === --- modules/http2/NWGNUmod_http2(revision 1741097) +++ modules/http2/NWGNUmod_http2(working copy) @@ -359,7 +359,7 @@ @echo $(DL) h2_ihash_clear,$(DL) >> $@ @echo $(DL) h2_ihash_count,$(DL) >> $@ @echo $(DL) h2_ihash_create,$(DL) >> $@ - @echo $(DL) h2_ihash_is_empty,$(DL) >> $@ + @echo $(DL) h2_ihash_empty,$(DL) >> $@ @echo $(DL) h2_ihash_iter,$(DL) >> $@ @echo $(DL) h2_ihash_remove,$(DL) >> $@ @echo $(DL) h2_iq_add,$(DL) >> $@ Index: modules/http2/NWGNUproxyht2 === --- modules/http2/NWGNUproxyht2 (revision 1741097) +++ modules/http2/NWGNUproxyht2 (working copy) @@ -230,7 +230,8 @@ ap_proxy_canon_netloc \ ap_proxy_canonenc \ ap_proxy_connect_backend \ - ap_proxy_connection_create \ + ap_proxy_connection_create \ + ap_proxy_connection_create_ex \ ap_proxy_cookie_reverse_map \ ap_proxy_determine_connection \ ap_proxy_location_reverse_map \ Index: modules/ssl/NWGNUmakefile === --- modules/ssl/NWGNUmakefile (revision 1741097) +++ modules/ssl/NWGNUmakefile (working copy) @@ -55,6 +55,7 @@ $(SRC)/include \ $(STDMOD)/cache \ $(STDMOD)/generators \ + $(STDMOD)/proxy \ $(SERVER)/mpm/NetWare \ $(NWOS) \ $(EOLIST) The EOL problem with NWGNUproxyht2 caused the symbol to be apparently added twice. - Unable (at this time) to work out the following error: Building D:/Projects/svn/httpd-trunk/modules/proxy Calling NWGNUproxy LINK obj_release/proxy.nlm ### mwldnlm Linker Error: # Undefined symbol: proxy_hook_get_section_post_config in # Export list ### mwldnlm Linker Error: # Undefined symbol: proxy_hook_section_post_config in # Export list I suspect this is due to an .awk script assumption that these two also exist, but it may also? be a extra source file needed for the build. With \http2 tweaked as noted, builds fine with nghttp2 v1.10.0. Regards Norm
Re: svn commit: r1739876 - /httpd/httpd/branches/2.4.x/STATUS
On Tue, Apr 26, 2016 at 10:48 PM, William A Rowe Jr wrote: > On Tue, Apr 26, 2016 at 3:47 PM, William A Rowe Jr > wrote: >> >> Reviewing the applicable patch, the client, request and protocol now >> appear > > > ... the client, vhost and protocol now appear ... > >> >> to persist for idle connections, but the request is still NULL? >> >> Is this by design? Or is something missing from the patch? Is it different behaviour than 2.4.18 (it shouldn't)? We are discussing different issues/solutions in PR 59333...
Re: TIL
On Tue, Apr 26, 2016 at 4:49 PM, Stefan Eissing wrote: > Today I Learned the difference between writing > DATA + META > and > DATA + META + FLUSH > to the core output filters. I am astonished that > my code ever worked. > > Seriously, what is the reason for this kind of > implementation? Do you mean why META could be destroyed before (setaside-)DATA, in remove_empty_buckets()? > I would like to pass META buckets > in non-blocking way and *not* lose the order of > bucket destruction. Any explanation or advice is > appreciated! You'd want to setaside (some) META buckets with DATA (in order), right? At least for EOR buckets, that would keep requests in memory longer than necessary, but maybe some other META are worth it... Regards, Yann.
Re: svn commit: r1739876 - /httpd/httpd/branches/2.4.x/STATUS
On Tue, Apr 26, 2016 at 3:47 PM, William A Rowe Jr wrote: > Reviewing the applicable patch, the client, request and protocol now appear > ... the client, vhost and protocol now appear ... > to persist for idle connections, but the request is still NULL? > > Is this by design? Or is something missing from the patch? > > On Tue, Apr 19, 2016 at 4:19 AM, wrote: > >> Author: rpluem >> Date: Tue Apr 19 09:19:44 2016 >> New Revision: 1739876 >> >> URL: http://svn.apache.org/viewvc?rev=1739876&view=rev >> Log: >> * Vote >> >> Modified: >> httpd/httpd/branches/2.4.x/STATUS >> >> Modified: httpd/httpd/branches/2.4.x/STATUS >> URL: >> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1739876&r1=1739875&r2=1739876&view=diff >> >> == >> --- httpd/httpd/branches/2.4.x/STATUS (original) >> +++ httpd/httpd/branches/2.4.x/STATUS Tue Apr 19 09:19:44 2016 >> @@ -191,7 +191,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: >> trunk patch: http://svn.apache.org/r1739193 >> 2.4.x patch: trunk works (modulo CHANGES) or >> >> http://home.apache.org/~ylavic/patches/httpd-2.4.x-scoreboard_preserve-v2.patch >> - +1: ylavic >> + +1: ylavic, rpluem >> ylavic: diff with 2.4.18 after this merge: >> >> http://home.apache.org/~ylavic/patches/scoreboard-2.4.18.diff >> >> >> >> >
Re: svn commit: r1739876 - /httpd/httpd/branches/2.4.x/STATUS
Reviewing the applicable patch, the client, request and protocol now appear to persist for idle connections, but the request is still NULL? Is this by design? Or is something missing from the patch? On Tue, Apr 19, 2016 at 4:19 AM, wrote: > Author: rpluem > Date: Tue Apr 19 09:19:44 2016 > New Revision: 1739876 > > URL: http://svn.apache.org/viewvc?rev=1739876&view=rev > Log: > * Vote > > Modified: > httpd/httpd/branches/2.4.x/STATUS > > Modified: httpd/httpd/branches/2.4.x/STATUS > URL: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1739876&r1=1739875&r2=1739876&view=diff > > == > --- httpd/httpd/branches/2.4.x/STATUS (original) > +++ httpd/httpd/branches/2.4.x/STATUS Tue Apr 19 09:19:44 2016 > @@ -191,7 +191,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: > trunk patch: http://svn.apache.org/r1739193 > 2.4.x patch: trunk works (modulo CHANGES) or > > http://home.apache.org/~ylavic/patches/httpd-2.4.x-scoreboard_preserve-v2.patch > - +1: ylavic > + +1: ylavic, rpluem > ylavic: diff with 2.4.18 after this merge: > > http://home.apache.org/~ylavic/patches/scoreboard-2.4.18.diff > > > >
TIL
Today I Learned the difference between writing DATA + META and DATA + META + FLUSH to the core output filters. I am astonished that my code ever worked. Seriously, what is the reason for this kind of implementation? I would like to pass META buckets in non-blocking way and *not* lose the order of bucket destruction. Any explanation or advice is appreciated! Cheers, Stefan
Re: svn commit: r1740987 - in /httpd/httpd/trunk/docs/manual/style: latex/quickreference.xsl latex/synopsis.xsl xsl/quickreference.xsl xsl/synopsis.xsl
Hi Yann, 2016-04-26 12:07 GMT+02:00 Yann Ylavic : > On Tue, Apr 26, 2016 at 11:55 AM, Yann Ylavic > wrote: > > [CC docs@] > > > > On Tue, Apr 26, 2016 at 11:51 AM, Yann Ylavic > wrote: > >> On Tue, Apr 26, 2016 at 11:47 AM, wrote: > >>> Author: ylavic > >>> Date: Tue Apr 26 09:47:46 2016 > >>> New Revision: 1740987 > >>> > >>> URL: http://svn.apache.org/viewvc?rev=1740987&view=rev > >>> Log: > >>> Introduce 'proxy section' context? > >> > >> This commit does not seem to work, I declared 'proxy section' (with > >> id='proxy') just like and wherever eg. 'server config' (with > >> id='serverconfig') is already declared , but the context is empty in > >> html files when I make docs (locally). > >> > >> Any idea? > > More precisely, the commit fixes the error about unknown 'proxy > section' context (new) in mod_ssl.xml (from r1740967) when "make docs" > is run, but still the context is empty in generated html files. > I believe that you should also add the related style/lang references like: Index: docs/manual/style/lang/en.xml === --- docs/manual/style/lang/en.xml (revision 1740989) +++ docs/manual/style/lang/en.xml (working copy) @@ -97,6 +97,7 @@ virtual host directory .htaccess +proxy config Directives I just tested it and it seems working. Probably you'll need to add it to all the files under lang/ do be consistent. Let me know if it helps! Regards, Luca
Re: svn commit: r1740987 - in /httpd/httpd/trunk/docs/manual/style: latex/quickreference.xsl latex/synopsis.xsl xsl/quickreference.xsl xsl/synopsis.xsl
On Tue, Apr 26, 2016 at 11:55 AM, Yann Ylavic wrote: > [CC docs@] > > On Tue, Apr 26, 2016 at 11:51 AM, Yann Ylavic wrote: >> On Tue, Apr 26, 2016 at 11:47 AM, wrote: >>> Author: ylavic >>> Date: Tue Apr 26 09:47:46 2016 >>> New Revision: 1740987 >>> >>> URL: http://svn.apache.org/viewvc?rev=1740987&view=rev >>> Log: >>> Introduce 'proxy section' context? >> >> This commit does not seem to work, I declared 'proxy section' (with >> id='proxy') just like and wherever eg. 'server config' (with >> id='serverconfig') is already declared , but the context is empty in >> html files when I make docs (locally). >> >> Any idea? More precisely, the commit fixes the error about unknown 'proxy section' context (new) in mod_ssl.xml (from r1740967) when "make docs" is run, but still the context is empty in generated html files.
Re: svn commit: r1740987 - in /httpd/httpd/trunk/docs/manual/style: latex/quickreference.xsl latex/synopsis.xsl xsl/quickreference.xsl xsl/synopsis.xsl
[CC docs@] On Tue, Apr 26, 2016 at 11:51 AM, Yann Ylavic wrote: > On Tue, Apr 26, 2016 at 11:47 AM, wrote: >> Author: ylavic >> Date: Tue Apr 26 09:47:46 2016 >> New Revision: 1740987 >> >> URL: http://svn.apache.org/viewvc?rev=1740987&view=rev >> Log: >> Introduce 'proxy section' context? > > This commit does not seem to work, I declared 'proxy section' (with > id='proxy') just like and wherever eg. 'server config' (with > id='serverconfig') is already declared , but the context is empty in > html files when I make docs (locally). > > Any idea?
Re: svn commit: r1740987 - in /httpd/httpd/trunk/docs/manual/style: latex/quickreference.xsl latex/synopsis.xsl xsl/quickreference.xsl xsl/synopsis.xsl
On Tue, Apr 26, 2016 at 11:47 AM, wrote: > Author: ylavic > Date: Tue Apr 26 09:47:46 2016 > New Revision: 1740987 > > URL: http://svn.apache.org/viewvc?rev=1740987&view=rev > Log: > Introduce 'proxy section' context? This commit does not seem to work, I declared 'proxy section' (with id='proxy') just like and wherever eg. 'server config' (with id='serverconfig') is already declared , but the context is empty in html files when I make docs (locally). Any idea?
Re: svn commit: r1740928 - in /httpd/httpd/trunk: ./ include/ modules/http2/ modules/proxy/ modules/ssl/ server/
On Tue, Apr 26, 2016 at 11:00 AM, Ruediger Pluem wrote:
>
> On 04/26/2016 02:04 AM, yla...@apache.org wrote:
>> static int ssl_hook_pre_connection(conn_rec *c, void *csd)
>> {
>> -
>> SSLSrvConfigRec *sc;
>> SSLConnRec *sslconn = myConnConfig(c);
>>
>> -if (sslconn) {
>> -sc = mySrvConfig(sslconn->server);
>> -}
>> -else {
>> -sc = mySrvConfig(c->base_server);
>> -}
>> /*
>> * Immediately stop processing if SSL is disabled for this connection
>> */
>> -if (c->master || !(sc && (sc->enabled == SSL_ENABLED_TRUE ||
>> - (sslconn && sslconn->is_proxy
>> -{
>> +if (ssl_engine_status(c, sslconn) != OK) {
>> return DECLINED;
>> }
>>
>> -/*
>> - * Create SSL context
>> - */
>> -if (!sslconn) {
>> -sslconn = ssl_init_connection_ctx(c);
>> +if (sslconn) {
>> +sc = mySrvConfig(sslconn->server);
>> }
>> -
>> -if (sslconn->disabled) {
>> -return DECLINED;
>> +else {
>> +sc = mySrvConfig(c->base_server);
>> }
>
> We have a change in behaviour here. We no longer guarantee that we have an
> sslconn created and connected to c if SSL is
> enabled. Is this intended?
Actually ssl_init_connection_ctx(c) is done by
ssl_init_ssl_connection() called just below (on return).
Regards,
Yann.
Re: svn commit: r1740928 - in /httpd/httpd/trunk: ./ include/ modules/http2/ modules/proxy/ modules/ssl/ server/
On 04/26/2016 02:04 AM, yla...@apache.org wrote:
> Author: ylavic
> Date: Tue Apr 26 00:04:57 2016
> New Revision: 1740928
>
> URL: http://svn.apache.org/viewvc?rev=1740928&view=rev
> Log:
> mod_proxy, mod_ssl: Handle SSLProxy* directives in sections,
> allowing different TLS configurations per backend.
>
>
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/include/http_config.h
> httpd/httpd/trunk/modules/http2/h2_h2.c
> httpd/httpd/trunk/modules/http2/mod_proxy_http2.c
> httpd/httpd/trunk/modules/proxy/mod_proxy.c
> httpd/httpd/trunk/modules/proxy/mod_proxy.h
> httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c
> httpd/httpd/trunk/modules/proxy/mod_proxy_ftp.c
> httpd/httpd/trunk/modules/proxy/mod_proxy_http.c
> httpd/httpd/trunk/modules/proxy/mod_proxy_wstunnel.c
> httpd/httpd/trunk/modules/proxy/proxy_util.c
> httpd/httpd/trunk/modules/ssl/mod_ssl.c
> httpd/httpd/trunk/modules/ssl/mod_ssl.h
> httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
> httpd/httpd/trunk/modules/ssl/ssl_engine_init.c
> httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
> httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
> httpd/httpd/trunk/modules/ssl/ssl_private.h
> httpd/httpd/trunk/server/config.c
> httpd/httpd/trunk/server/core.c
>
> Modified: httpd/httpd/trunk/modules/ssl/mod_ssl.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/mod_ssl.c?rev=1740928&r1=1740927&r2=1740928&view=diff
> ==
> --- httpd/httpd/trunk/modules/ssl/mod_ssl.c (original)
> +++ httpd/httpd/trunk/modules/ssl/mod_ssl.c Tue Apr 26 00:04:57 2016
> @@ -561,34 +605,21 @@ static apr_port_t ssl_hook_default_port(
>
> static int ssl_hook_pre_connection(conn_rec *c, void *csd)
> {
> -
> SSLSrvConfigRec *sc;
> SSLConnRec *sslconn = myConnConfig(c);
>
> -if (sslconn) {
> -sc = mySrvConfig(sslconn->server);
> -}
> -else {
> -sc = mySrvConfig(c->base_server);
> -}
> /*
> * Immediately stop processing if SSL is disabled for this connection
> */
> -if (c->master || !(sc && (sc->enabled == SSL_ENABLED_TRUE ||
> - (sslconn && sslconn->is_proxy
> -{
> +if (ssl_engine_status(c, sslconn) != OK) {
> return DECLINED;
> }
>
> -/*
> - * Create SSL context
> - */
> -if (!sslconn) {
> -sslconn = ssl_init_connection_ctx(c);
> +if (sslconn) {
> +sc = mySrvConfig(sslconn->server);
> }
> -
> -if (sslconn->disabled) {
> -return DECLINED;
> +else {
> +sc = mySrvConfig(c->base_server);
> }
We have a change in behaviour here. We no longer guarantee that we have an
sslconn created and connected to c if SSL is
enabled. Is this intended?
>
> /*
Regards
Rüdiger
