Re: balancer-manager docs

[Stefan Eissing]

Very nice!

> Am 11.02.2016 um 18:46 schrieb Jim Jagielski :
> 
> A rough and very brief framework of such a guide is now available...
> 
>http://httpd.apache.org/docs/trunk/howto/reverse_proxy.html
> 
> On 2016-02-10 06:21, Luca Toscano  wrote: 
>> 2016-02-10 10:33 GMT+01:00 Stefan Eissing :
>> 
>>> If you write one, I write one for http2! :-)
>>> 
>>> 
>> +1+1+1+1 :)
>> 
> --
> Sent via Pony Mail for dev@httpd.apache.org. 
> View this email online at:
> https://pony-poc.apache.org/list.html?dev@httpd.apache.org

Re: svn commit: r1729929 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h server/core.c

[Yann Ylavic]

On Fri, Feb 12, 2016 at 2:04 AM,   wrote:
> Author: wrowe
> Date: Fri Feb 12 01:04:58 2016
> New Revision: 1729929
>
[]
> Modified: httpd/httpd/trunk/include/httpd.h
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/include/httpd.h?rev=1729929=1729928=1729929=diff
> ==
> --- httpd/httpd/trunk/include/httpd.h (original)
> +++ httpd/httpd/trunk/include/httpd.h Fri Feb 12 01:04:58 2016
> @@ -1056,6 +1056,16 @@ struct request_rec {
>  apr_table_t *trailers_in;
>  /** MIME trailer environment from the response */
>  apr_table_t *trailers_out;
> +
> +/** Originator's DNS name, if known.  NULL if DNS hasn't been checked,
> + *  "" if it has and no address was found.  N.B. Only access this though
> + *  ap_get_useragent_host() */
> +char *useragent_host;

const char * ?
Christophe has made some changes recently to add const to r->protocol
(trunk only, can't be backported...), I think we shoudn't introduce
new char* in "public" structs.

> +/** have we done double-reverse DNS? -1 yes/failure, 0 not yet,
> + *  1 yes/success
> + *  TODO: 2 bit signed bitfield when this structure is compacted
> + */
> +int double_reverse;
>  };

I see this TODO about bitfield, but never seen it done in your
commits, so I wonder where Rainer's warning comes from...
Anyway, once backported (as you propose), we can hardly change it.

Regards,
Yann.

Re: svn commit: r1729929 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h server/core.c

[William A Rowe Jr]

On Feb 12, 2016 2:24 AM, "Yann Ylavic"  wrote:
>
> On Fri, Feb 12, 2016 at 2:04 AM,   wrote:
> > Author: wrowe
> > Date: Fri Feb 12 01:04:58 2016
> > New Revision: 1729929
> >

> > +/** Originator's DNS name, if known.  NULL if DNS hasn't been
checked,
> > + *  "" if it has and no address was found.  N.B. Only access this
though
> > + *  ap_get_useragent_host() */
> > +char *useragent_host;
>
> const char * ?
> Christophe has made some changes recently to add const to r->protocol
> (trunk only, can't be backported...), I think we shoudn't introduce
> new char* in "public" structs.

While I would generally agree, the note states you must not access this
member directly, so it seems irrelevant.  But such a change should be
harmless.

> > +/** have we done double-reverse DNS? -1 yes/failure, 0 not yet,
> > + *  1 yes/success
> > + *  TODO: 2 bit signed bitfield when this structure is compacted
> > + */
> > +int double_reverse;
> >  };
>
> I see this TODO about bitfield, but never seen it done in your
> commits, so I wonder where Rainer's warning comes from...
> Anyway, once backported (as you propose), we can hardly change it.

Precisely, it will NOT change in 2.4 and should not change, and is only
applicable to trunk.  I should have omitted from the initial commit.

If we define this as int :2 and add a second int :2, none of the c
standards promise that the initial 2-bit value maintains its previous
alignment.  The alignment is undefined.

When we refactor trunk structures in anticipation of 2.6/3.0, that will be
the time to permanently park short bit values adjacent to one another.

If backported, we should redact the comment.

Cheers,

Bill

Re: balancer-manager docs

[Daniel]

Looks very nice indeed! For being a "rough" version looks quite complete.
Also the diagram is a cool addition to help people understand how reverse
proxying works.

I think the examples may need some adjusting with the matching slashes:

ProxyPass "/" "http://www.example.com;
should be:
ProxyPass / http://www.example.com/
(I removed the quotes because they are not necessary)

and
ProxyPass "/images" "http://www.example.com;
should be:
ProxyPass /images/ http://www.example.com/


Cheers!



El vie., 12 feb. 2016 a las 9:48, Stefan Eissing (<
stefan.eiss...@greenbytes.de>) escribió:

> Very nice!
>
> > Am 11.02.2016 um 18:46 schrieb Jim Jagielski :
> >
> > A rough and very brief framework of such a guide is now available...
> >
> >http://httpd.apache.org/docs/trunk/howto/reverse_proxy.html
> >
> > On 2016-02-10 06:21, Luca Toscano  wrote:
> >> 2016-02-10 10:33 GMT+01:00 Stefan Eissing  >:
> >>
> >>> If you write one, I write one for http2! :-)
> >>>
> >>>
> >> +1+1+1+1 :)
> >>
> > --
> > Sent via Pony Mail for dev@httpd.apache.org.
> > View this email online at:
> > https://pony-poc.apache.org/list.html?dev@httpd.apache.org
>
>

Re: httpd-trunk/modules/http2 gets a proxy

[Stefan Eissing]

Thanks. Added in r1729969.

> Am 11.02.2016 um 21:52 schrieb NormW :
> 
> 

Re: svn commit: r1729927 - in /httpd/httpd/trunk/modules/ssl: ssl_engine_kernel.c ssl_private.h

[Ruediger Pluem]

On 02/12/2016 01:44 AM, rj...@apache.org wrote:
> Author: rjung
> Date: Fri Feb 12 00:44:22 2016
> New Revision: 1729927
> 
> URL: http://svn.apache.org/viewvc?rev=1729927=rev
> Log:
> Support for OpenSSL 1.1.0:
> - further improvements for renegotiation
> No more test suite failures for reneg,
> but still using not so nice polling.
> 
> Modified:
> httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
> httpd/httpd/trunk/modules/ssl/ssl_private.h
> 
> Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=1729927=1729926=1729927=diff
> ==
> --- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
> +++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Fri Feb 12 00:44:22 2016
> @@ -1040,16 +1040,20 @@ int ssl_hook_Access(request_rec *r)
>  /* XXX: Polling is bad, alternatives? */
>  for (i = 0; i < SSL_HANDSHAKE_MAX_POLLS; i++) {
>  has_buffered_data(r);
> -if (sslconn->ssl == NULL || SSL_is_init_finished(ssl)) {
> +if (sslconn->ssl == NULL ||
> +sslconn->reneg_state == RENEG_DONE ||
> +sslconn->reneg_state == RENEG_ALLOW) {
>  break;
>  }
>  apr_sleep(SSL_HANDSHAKE_POLL_MS);
>  }
>  ap_log_rerror(APLOG_MARK, APLOG_TRACE2, 0, r, APLOGNO()
>"Renegotiation loop %d iterations, "
> +  "reneg_state=%d, "
>"in_init=%d, init_finished=%d, "
>"state=%s, sslconn->ssl=%s, peer_certs=%s",
> -  i, SSL_in_init(ssl), SSL_is_init_finished(ssl),
> +  i, sslconn->reneg_state,
> +  SSL_in_init(ssl), SSL_is_init_finished(ssl),
>SSL_state_string_long(ssl),
>sslconn->ssl != NULL ? "yes" : "no",
>SSL_get_peer_certificate(ssl) != NULL ? "yes" : 
> "no");
> @@ -2142,6 +2146,18 @@ void ssl_callback_Info(const SSL *ssl, i
>  }
>  #endif
>  }
> +#if OPENSSL_VERSION_NUMBER >= 0x1000L

Is this correct or should it be 0x1010L instead?

Regards

Rüdiger

> +else if ((where & SSL_CB_HANDSHAKE_START) && scr->reneg_state == 
> RENEG_ALLOW) {
> +scr->reneg_state = RENEG_STARTED;
> +}
> +else if ((where & SSL_CB_HANDSHAKE_DONE) && scr->reneg_state == 
> RENEG_STARTED) {
> +scr->reneg_state = RENEG_DONE;
> +}
> +else if ((where & SSL_CB_ALERT) &&
> + (scr->reneg_state == RENEG_ALLOW || scr->reneg_state == 
> RENEG_STARTED)) {
> +scr->reneg_state = RENEG_ALERT;
> +}
> +#endif
>  /* If the first handshake is complete, change state to reject any
>   * subsequent client-initiated renegotiation. */
>  else if ((where & SSL_CB_HANDSHAKE_DONE) && scr->reneg_state == 
> RENEG_INIT) {
> 
> Modified: httpd/httpd/trunk/modules/ssl/ssl_private.h
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?rev=1729927=1729926=1729927=diff
> ==
> --- httpd/httpd/trunk/modules/ssl/ssl_private.h (original)
> +++ httpd/httpd/trunk/modules/ssl/ssl_private.h Fri Feb 12 00:44:22 2016
> @@ -444,12 +444,17 @@ typedef struct {
>   * partial fix for CVE-2009-3555. */
>  enum {
>  RENEG_INIT = 0, /* Before initial handshake */
> -RENEG_REJECT, /* After initial handshake; any client-initiated
> -   * renegotiation should be rejected */
> -RENEG_ALLOW, /* A server-initiated renegotiation is taking
> -  * place (as dictated by configuration) */
> -RENEG_ABORT /* Renegotiation initiated by client, abort the
> - * connection */
> +RENEG_REJECT,   /* After initial handshake; any client-initiated
> + * renegotiation should be rejected */
> +RENEG_ALLOW,/* A server-initiated renegotiation is taking
> + * place (as dictated by configuration) */
> +#if OPENSSL_VERSION_NUMBER >= 0x1000L

Same question as above

> +RENEG_STARTED,  /* A renegotiation has started after RENEG_ALLOW */
> +RENEG_DONE, /* A renegotiation has finished after RENEG_STARTED 
> */
> +RENEG_ALERT,/* A renegotiation has finished with an SSL Alert */
> +#endif
> +RENEG_ABORT /* Renegotiation initiated by client, abort the
> + * connection */
>  } reneg_state;
>  
>  server_rec *server;
> 
> 
> 

Regards

Rüdiger

Thoughts on using HW for httpd?

[Daniel Gruno]

Hi folks,
as some may know, ComDev is trialling a new thing called 'Help Wanted!'
at https://helpwanted.apache.org/

I've added a few example entries for httpd, and I'm wondering if this is
something we would want to plug into our web site?

You can see an example web site widget at
https://helpwanted.apache.org/wtest.html (top one shows httpd)

It's an easy way to identify which tasks we'd love to see someone get
started on (and has the benefit of being able to assign difficulty
levels, skills needed etc to a task), and judging from the input on the
existing tasks, it seems to attract people towards projects.

Thoughts? flames? snark? :)

With regards,
Daniel.

Re: [users@httpd] Block access to "OPTIONS *"

[Yann Ylavic]

Following up below users@ discussion on dev@...

On Fri, Feb 12, 2016 at 12:47 PM, Yann Ylavic  wrote:
> On Fri, Feb 12, 2016 at 10:47 AM, Daniel  wrote:
>> The typical way to block OPTIONS in 2.2 does not need mod_rewrite at all
>> IIRC. You just add this in your location/directory:
>> 
>> deny from all
>> 
>>
>> and will return 403 if you try OPTIONS method there
>
> That wouldn't work because the replies to OPTIONS requests happen
> before in the map_to_storage hook, that is before the authz hooks
> (Toomas tried that already).

That's what I observed in my testing with the following configuration:
>
>  # matches / and *
> 
>Deny from all  # 2.2
>Require all denied # 2.4
> 
>   
>
> For now I could only make it work with:
>   RewriteEngine on
>   RewriteOptions AllowAnyURI # for * to be taken into account by mod_rewrite
>   RewriteCond %{REQUEST_METHOD} OPTIONS
>   RewriteRule ^ - [R=405,L]
>   RewriteRule ^[^/] - [R=403,L]
> which should be the first rewrite rules for AllowAnyURI to not be
> "dangerous" for further rules (if any) failing to match the leading
> slash.

That's not an elegant solution...

So I tried this change:

Index: modules/http/http_core.c
===
--- modules/http/http_core.c(revision 1729486)
+++ modules/http/http_core.c(working copy)
@@ -271,7 +271,7 @@ static int http_create_request(request_rec *r)
 static int http_send_options(request_rec *r)
 {
 if ((r->method_number == M_OPTIONS) && r->uri && (r->uri[0] == '*') &&
- (r->uri[1] == '\0')) {
+ (r->uri[1] == '\0') && !ap_some_auth_required(r)) {
 return DONE;   /* Send HTTP pong, without Allow header */
 }
 return DECLINED;
--

so to bypass http_send_options() if OPTIONS is ed (here
ap_some_auth_required() is a misnomer (deprecated btw), what it really
does is returning whether there is a Limit on the requested method,
AIUI though).

But ap_some_auth_required() always return false here, because there is
no mod_authz_core's per_dir_config (at this hook/point only?), so the
function has nothing to check.

Any insight on whether or not this is a reasonable approach and why it
does not work much appreciated :)

Regards,
Yann.

Re: [users@httpd] Block access to "OPTIONS *"

[Yann Ylavic]

On Fri, Feb 12, 2016 at 1:28 PM, Jim Jagielski  wrote:
> Blocking OPTIONS has a long and illustrious history...
> I am -0 on doing anything more related to it ;)

OK, I see, let's users@ play with the workaround then :)

Re: Thoughts on using HW for httpd?

[Luca Toscano]

+1!

I really like this idea, especially for new committers/volunteers like me
looking for things to work on. I would also add a section related to "how
to find help if you get stuck" or "How to send your code/work for review".

Really interested, if you need any help I'll be available :)

Luca



2016-02-12 13:35 GMT+01:00 Yann Ylavic :

> +1!
>
> On Fri, Feb 12, 2016 at 1:27 PM, Jim Jagielski  wrote:
> > /me like
> >
> >> On Feb 12, 2016, at 7:20 AM, Daniel Gruno  wrote:
> >>
> >> Hi folks,
> >> as some may know, ComDev is trialling a new thing called 'Help Wanted!'
> >> at https://helpwanted.apache.org/
> >>
> >> I've added a few example entries for httpd, and I'm wondering if this is
> >> something we would want to plug into our web site?
> >>
> >> You can see an example web site widget at
> >> https://helpwanted.apache.org/wtest.html (top one shows httpd)
> >>
> >> It's an easy way to identify which tasks we'd love to see someone get
> >> started on (and has the benefit of being able to assign difficulty
> >> levels, skills needed etc to a task), and judging from the input on the
> >> existing tasks, it seems to attract people towards projects.
> >>
> >> Thoughts? flames? snark? :)
> >>
> >> With regards,
> >> Daniel.
> >
>

Re: svn commit: r1729929 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h server/core.c

[Yann Ylavic]

On Fri, Feb 12, 2016 at 10:49 AM, William A Rowe Jr  wrote:
> On Feb 12, 2016 2:24 AM, "Yann Ylavic"  wrote:
>>
>> I see this TODO about bitfield, but never seen it done in your
>> commits, so I wonder where Rainer's warning comes from...
>> Anyway, once backported (as you propose), we can hardly change it.
>
> Precisely, it will NOT change in 2.4 and should not change, and is only
> applicable to trunk.  I should have omitted from the initial commit.
>
> If we define this as int :2 and add a second int :2, none of the c standards
> promise that the initial 2-bit value maintains its previous alignment.  The
> alignment is undefined.

Indeed, and as such we can't make any promise about bits
alignment/order wrt to the underlying int, and the user can't expect
any either.

As you noticed, it's not possible to get the address of a bitfield (it
makes no sense), and we don't union the bitfields with a true int, so
the user would have to do things like "int *bitmask = (int *)&((char
*)r)[APR_OFFSETOF(r, useragent_host) + sizeof(r->useragent_host)]" to
start playing with the bits, and IMO that deserves a breakage if we
add a new bitfield!

So I don't thing we should worry about compatibility of bitfields wrt
added bits, the goal is to be able to add a new field without
increasing the size of the struct (for something that requires only a
few bits).

Aside note: with an int:2 bitfield, the possible values are 0 (00), 1
(01), -2 (10) and -1 (11), that may be surprising, although that fits
your description of double_reverse.
IMHO signed bitfields should be avoided, and I don't know if compilers
are kind enough (nor allowed) to pack successive signed/unsigned
bitfields, probably yes but otherwise we may lose extensibility of
"int double_reverse:2" though...
So we may prefer "unsigned int double_reverse:2" (and change the
description) so that we can later add a single bit that equals 1 and
not -1.

Regards,
Yann.

Re: Thoughts on using HW for httpd?

[Daniel Gruno]

On 02/12/2016 02:06 PM, Luca Toscano wrote:
> +1!
> 
> I really like this idea, especially for new committers/volunteers like
> me looking for things to work on. I would also add a section related to
> "how to find help if you get stuck" or "How to send your code/work for
> review".

I think the 'how to' stuff would be unique to httpd and thus belong in
our docs area. HW has a 'contribution help URL' parameter you can set,
so we could just point that to whatever contributor docs we have/want.

> 
> Really interested, if you need any help I'll be available :) 

Glad to hear that :) As you are a committer, you already have access to
add tasks on HW (click the 'add/edit tasks' link) if you can think of
anything we might want people to look into :)

With regards,
Daniel.
> 
> Luca
> 
> 
> 
> 2016-02-12 13:35 GMT+01:00 Yann Ylavic  >:
> 
> +1!
> 
> On Fri, Feb 12, 2016 at 1:27 PM, Jim Jagielski  > wrote:
> > /me like
> >
> >> On Feb 12, 2016, at 7:20 AM, Daniel Gruno  > wrote:
> >>
> >> Hi folks,
> >> as some may know, ComDev is trialling a new thing called 'Help
> Wanted!'
> >> at https://helpwanted.apache.org/
> >>
> >> I've added a few example entries for httpd, and I'm wondering if
> this is
> >> something we would want to plug into our web site?
> >>
> >> You can see an example web site widget at
> >> https://helpwanted.apache.org/wtest.html (top one shows httpd)
> >>
> >> It's an easy way to identify which tasks we'd love to see someone get
> >> started on (and has the benefit of being able to assign difficulty
> >> levels, skills needed etc to a task), and judging from the input
> on the
> >> existing tasks, it seems to attract people towards projects.
> >>
> >> Thoughts? flames? snark? :)
> >>
> >> With regards,
> >> Daniel.
> >
> 
> 

Re: [users@httpd] Block access to "OPTIONS *"

[Daniel Gruno]

On 02/12/2016 01:28 PM, Jim Jagielski wrote:
> Blocking OPTIONS has a long and illustrious history...
> I am -0 on doing anything more related to it ;)
> 

Isn't that why we have the optional mod_allowmethods these days anyway...

With regards,
Daniel.

Re: svn commit: r1729927 - in /httpd/httpd/trunk/modules/ssl: ssl_engine_kernel.c ssl_private.h

[Rainer Jung]

Yes, thanks for the review!

Wrong checked version in "#if" (copy typo) fixed with r1729998.

Regards,

Rainer

Am 12.02.2016 um 11:25 schrieb Ruediger Pluem:



On 02/12/2016 01:44 AM, rj...@apache.org wrote:

Author: rjung
Date: Fri Feb 12 00:44:22 2016
New Revision: 1729927

URL: http://svn.apache.org/viewvc?rev=1729927=rev
Log:
Support for OpenSSL 1.1.0:
- further improvements for renegotiation
No more test suite failures for reneg,
but still using not so nice polling.

Modified:
 httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
 httpd/httpd/trunk/modules/ssl/ssl_private.h

Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c?rev=1729927=1729926=1729927=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_kernel.c Fri Feb 12 00:44:22 2016
@@ -1040,16 +1040,20 @@ int ssl_hook_Access(request_rec *r)
  /* XXX: Polling is bad, alternatives? */
  for (i = 0; i < SSL_HANDSHAKE_MAX_POLLS; i++) {
  has_buffered_data(r);
-if (sslconn->ssl == NULL || SSL_is_init_finished(ssl)) {
+if (sslconn->ssl == NULL ||
+sslconn->reneg_state == RENEG_DONE ||
+sslconn->reneg_state == RENEG_ALLOW) {
  break;
  }
  apr_sleep(SSL_HANDSHAKE_POLL_MS);
  }
  ap_log_rerror(APLOG_MARK, APLOG_TRACE2, 0, r, APLOGNO()
"Renegotiation loop %d iterations, "
+  "reneg_state=%d, "
"in_init=%d, init_finished=%d, "
"state=%s, sslconn->ssl=%s, peer_certs=%s",
-  i, SSL_in_init(ssl), SSL_is_init_finished(ssl),
+  i, sslconn->reneg_state,
+  SSL_in_init(ssl), SSL_is_init_finished(ssl),
SSL_state_string_long(ssl),
sslconn->ssl != NULL ? "yes" : "no",
SSL_get_peer_certificate(ssl) != NULL ? "yes" : 
"no");
@@ -2142,6 +2146,18 @@ void ssl_callback_Info(const SSL *ssl, i
  }
  #endif
  }
+#if OPENSSL_VERSION_NUMBER >= 0x1000L


Is this correct or should it be 0x1010L instead?

Regards

Rüdiger


+else if ((where & SSL_CB_HANDSHAKE_START) && scr->reneg_state == 
RENEG_ALLOW) {
+scr->reneg_state = RENEG_STARTED;
+}
+else if ((where & SSL_CB_HANDSHAKE_DONE) && scr->reneg_state == 
RENEG_STARTED) {
+scr->reneg_state = RENEG_DONE;
+}
+else if ((where & SSL_CB_ALERT) &&
+ (scr->reneg_state == RENEG_ALLOW || scr->reneg_state == 
RENEG_STARTED)) {
+scr->reneg_state = RENEG_ALERT;
+}
+#endif
  /* If the first handshake is complete, change state to reject any
   * subsequent client-initiated renegotiation. */
  else if ((where & SSL_CB_HANDSHAKE_DONE) && scr->reneg_state == 
RENEG_INIT) {

Modified: httpd/httpd/trunk/modules/ssl/ssl_private.h
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_private.h?rev=1729927=1729926=1729927=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_private.h (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_private.h Fri Feb 12 00:44:22 2016
@@ -444,12 +444,17 @@ typedef struct {
   * partial fix for CVE-2009-3555. */
  enum {
  RENEG_INIT = 0, /* Before initial handshake */
-RENEG_REJECT, /* After initial handshake; any client-initiated
-   * renegotiation should be rejected */
-RENEG_ALLOW, /* A server-initiated renegotiation is taking
-  * place (as dictated by configuration) */
-RENEG_ABORT /* Renegotiation initiated by client, abort the
- * connection */
+RENEG_REJECT,   /* After initial handshake; any client-initiated
+ * renegotiation should be rejected */
+RENEG_ALLOW,/* A server-initiated renegotiation is taking
+ * place (as dictated by configuration) */
+#if OPENSSL_VERSION_NUMBER >= 0x1000L


Same question as above


+RENEG_STARTED,  /* A renegotiation has started after RENEG_ALLOW */
+RENEG_DONE, /* A renegotiation has finished after RENEG_STARTED */
+RENEG_ALERT,/* A renegotiation has finished with an SSL Alert */
+#endif
+RENEG_ABORT /* Renegotiation initiated by client, abort the
+ * connection */
  } reneg_state;

  server_rec *server;





Regards

Rüdiger

Re: Thoughts on using HW for httpd?

[Jim Jagielski]

/me like

> On Feb 12, 2016, at 7:20 AM, Daniel Gruno  wrote:
> 
> Hi folks,
> as some may know, ComDev is trialling a new thing called 'Help Wanted!'
> at https://helpwanted.apache.org/
> 
> I've added a few example entries for httpd, and I'm wondering if this is
> something we would want to plug into our web site?
> 
> You can see an example web site widget at
> https://helpwanted.apache.org/wtest.html (top one shows httpd)
> 
> It's an easy way to identify which tasks we'd love to see someone get
> started on (and has the benefit of being able to assign difficulty
> levels, skills needed etc to a task), and judging from the input on the
> existing tasks, it seems to attract people towards projects.
> 
> Thoughts? flames? snark? :)
> 
> With regards,
> Daniel.

Re: [users@httpd] Block access to "OPTIONS *"

[Jim Jagielski]

Blocking OPTIONS has a long and illustrious history...
I am -0 on doing anything more related to it ;)

Re: [users@httpd] Block access to "OPTIONS *"

[Yann Ylavic]

On Fri, Feb 12, 2016 at 1:29 PM, Daniel Gruno  wrote:
> On 02/12/2016 01:28 PM, Jim Jagielski wrote:
>> Blocking OPTIONS has a long and illustrious history...
>> I am -0 on doing anything more related to it ;)
>>
>
> Isn't that why we have the optional mod_allowmethods these days anyway...

That looks nicer indeed, but the user is running 2.2...
Anyway, he should upgrade to benefit latest improvements :p

Regards,
Yann.

Re: Thoughts on using HW for httpd?

[Yann Ylavic]

+1!

On Fri, Feb 12, 2016 at 1:27 PM, Jim Jagielski  wrote:
> /me like
>
>> On Feb 12, 2016, at 7:20 AM, Daniel Gruno  wrote:
>>
>> Hi folks,
>> as some may know, ComDev is trialling a new thing called 'Help Wanted!'
>> at https://helpwanted.apache.org/
>>
>> I've added a few example entries for httpd, and I'm wondering if this is
>> something we would want to plug into our web site?
>>
>> You can see an example web site widget at
>> https://helpwanted.apache.org/wtest.html (top one shows httpd)
>>
>> It's an easy way to identify which tasks we'd love to see someone get
>> started on (and has the benefit of being able to assign difficulty
>> levels, skills needed etc to a task), and judging from the input on the
>> existing tasks, it seems to attract people towards projects.
>>
>> Thoughts? flames? snark? :)
>>
>> With regards,
>> Daniel.
>

Re: FYI: Backport of mod_proxy_hcheck

[Jim Jagielski]

The patchfile, minus docs, can be found at:

http://home.apache.org/~jim/patches/hcheck-2.4.patch

Thx!

Re: FYI: Backport of mod_proxy_hcheck

[Jim Jagielski]

I am following the way we've handled that struct before when
we've needed to adjust (eg: uds_path)...

> On Feb 12, 2016, at 9:14 AM, Yann Ylavic  wrote:
> 
> On Fri, Feb 12, 2016 at 2:50 PM, Jim Jagielski  wrote:
>> The patchfile, minus docs, can be found at:
>> 
>>http://home.apache.org/~jim/patches/hcheck-2.4.patch
> 
> How about the changes to struct proxy_worker_shared w.r.t. backportability?

Re: FYI: Backport of mod_proxy_hcheck

[Yann Ylavic]

On Fri, Feb 12, 2016 at 2:50 PM, Jim Jagielski  wrote:
> The patchfile, minus docs, can be found at:
>
> http://home.apache.org/~jim/patches/hcheck-2.4.patch

How about the changes to struct proxy_worker_shared w.r.t. backportability?

Re: mod_proxy_http2

[Rainer Jung]

I have renamed modules/http2/config.m4 to modules/http2/config2.m4 (note 
the "2" in front of the ".m4" suffix). AFAIK this will result in 
modules/http2 being handled after the module dirs which contain a normal 
config.m4. Thus the http2 modules get added after mod_proxy to the 
DSO_MODULES list and the generated httpd.conf will contain their 
LoadModule behind the ones for mod_proxy.


I have also added mod_proxy as a prerequisite in the m4 macro for 
mod_proxy_http2.


I hope it works as designed ...

Regards,

Rainer

Am 10.02.2016 um 16:41 schrieb Rainer Jung:

At this point just a reminder, I might look for it myself:

the config generated for me tries LoadModule for mod_proxy_http2 before
mod_proxy and fails, because it can't find the symbol mod_proxy. I guess
we need to ensure, that the LoadModule lines we generate for httpd.conf
put mod_proxy_http2 after the one for mod_proxy. The current other proxy
modules are already behind mod_proxy.

Re: httpd-trunk/modules/http2 gets a proxy

[Rainer Jung]

Am 12.02.2016 um 11:13 schrieb Stefan Eissing:

Thanks. Added in r1729969.


Am 11.02.2016 um 21:52 schrieb NormW :




I got confused. Which file now builds mod_proxy_http2 on Netware? I 
can't find it. Shouldn't we also need a 
modules/http2/NWGNUmod_proxy_http2 file?


Regards,

Rainer

Re: httpd-2.4 --enable-load-all-modules side-effect

[Rainer Jung]

Am 08.02.2016 um 20:47 schrieb Rainer Jung:

Hi Bill,

Am 08.02.2016 um 19:11 schrieb William A Rowe Jr:

./configure [...]
"--with-mods-shared=all" \
"--enable-mods-shared=all" \
"--enable-mpms-shared=all" \
"--enable-load-all-modules" \
"--with-mpm=worker" \

While this should be great for testing a variety of modules and
is very helpful for building it all, the resulting httpd.conf isn't quite
helpful...

LoadModule mpm_event_module modules/mod_mpm_event.so
LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
LoadModule mpm_worker_module modules/mod_mpm_worker.so

We obviously cannot load multiple mpm modules :)

Can someone more familiar with the --enable-load-all-modules
or --enable-mpms-shared/--with-mpm mechanics take a look at
fixing this behavior before we roll on to a 2.4.19 release?

If not, I will try to take a look, but the plate is pretty full with
other
half-completed projects here.


Could you apply r1729235 to your checkout and see whether it works for you?

The indentation of the shell snippets in the Makefile is broken, but
that's an older annoyance we can independently.


I have changed the impl a bit in 1730079. Maybe you can try some time.

Regards,

Rainer

rotatelogs and SIGTERM?

[Eric Covener]

Recall that 2.2 ran piped loggers under a shell until somewhat late in
life, and 2.4 runs them directly [by default].

rotatelogs currently doesn't do anything to block sigterm.  The
default ahndler for sigterm writes a short message to stderr, which is
the only reason I noticed.

It seems like a lose/lose scenario though:

If rotatelogs exits early due to sigterm before all writing ends of
the pipe are closed, it's not there to log the stragglers for e.g. a
graceful restart
If rotatelogs waits... then replacement rotatelogs processes are
likely to write to the same log [if using time based rotation].

Any other ideas/observations/trivia?

-- 
Eric Covener
cove...@gmail.com

Re: rotatelogs and SIGTERM?

[Yann Ylavic]

IIRC, solaris is doing things like that.
But here the shell would ignore SIGTERM (the trap may even be
superfluous since shells usually ignore it implicitly), so it
shouldn't be stopped by the signal and hence the message shouldn't
show up...

On Fri, Feb 12, 2016 at 10:40 PM, Eric Covener  wrote:
> I lost a sentence somewhere. On one platform I use, the default for
> SIGTERM writes a message to stderr.
>
> On Fri, Feb 12, 2016 at 4:37 PM, Yann Ylavic  wrote:
>> On Fri, Feb 12, 2016 at 8:25 PM, Eric Covener  wrote:
>>> Recall that 2.2 ran piped loggers under a shell until somewhat late in
>>> life, and 2.4 runs them directly [by default].
>>>
>>> rotatelogs currently doesn't do anything to block sigterm.  The
>>> default ahndler for sigterm writes a short message to stderr, which is
>>> the only reason I noticed.
>>
>> Maybe you could wrap rotatelogs in a script like:
>>
>> #!/bin/sh
>> trap '' TERM
>> /path/to/real/rotatelogs $@
>>
>> and then use:
>> ErrorLog |$/path/to/my/rotatelogs.sh ...
>>
>> in httpd.conf?
>
>
>
> --
> Eric Covener
> cove...@gmail.com

Re: rotatelogs and SIGTERM?

[Eric Covener]

On Fri, Feb 12, 2016 at 4:46 PM, Yann Ylavic  wrote:
> IIRC, solaris is doing things like that.
> But here the shell would ignore SIGTERM (the trap may even be
> superfluous since shells usually ignore it implicitly), so it
> shouldn't be stopped by the signal and hence the message shouldn't
> show up...
>
> On Fri, Feb 12, 2016 at 10:40 PM, Eric Covener  wrote:
>> I lost a sentence somewhere. On one platform I use, the default for
>> SIGTERM writes a message to stderr.
>>
>> On Fri, Feb 12, 2016 at 4:37 PM, Yann Ylavic  wrote:
>>> On Fri, Feb 12, 2016 at 8:25 PM, Eric Covener  wrote:
 Recall that 2.2 ran piped loggers under a shell until somewhat late in
 life, and 2.4 runs them directly [by default].

 rotatelogs currently doesn't do anything to block sigterm.  The
 default ahndler for sigterm writes a short message to stderr, which is
 the only reason I noticed.
>>>
>>> Maybe you could wrap rotatelogs in a script like:
>>>
>>> #!/bin/sh
>>> trap '' TERM
>>> /path/to/real/rotatelogs $@
>>>
>>> and then use:
>>> ErrorLog |$/path/to/my/rotatelogs.sh ...
>>>
>>> in httpd.conf?

Moreso trying to flush out if it's a good or bad idea, seems simple
enough to add to rotatelogs rather than requiring the wrapper.

Re: rotatelogs and SIGTERM?

[Yann Ylavic]

On Fri, Feb 12, 2016 at 8:25 PM, Eric Covener  wrote:
> Recall that 2.2 ran piped loggers under a shell until somewhat late in
> life, and 2.4 runs them directly [by default].
>
> rotatelogs currently doesn't do anything to block sigterm.  The
> default ahndler for sigterm writes a short message to stderr, which is
> the only reason I noticed.

Maybe you could wrap rotatelogs in a script like:

#!/bin/sh
trap '' TERM
/path/to/real/rotatelogs $@

and then use:
ErrorLog |$/path/to/my/rotatelogs.sh ...

in httpd.conf?

Re: rotatelogs and SIGTERM?

[Eric Covener]

I lost a sentence somewhere. On one platform I use, the default for
SIGTERM writes a message to stderr.

On Fri, Feb 12, 2016 at 4:37 PM, Yann Ylavic  wrote:
> On Fri, Feb 12, 2016 at 8:25 PM, Eric Covener  wrote:
>> Recall that 2.2 ran piped loggers under a shell until somewhat late in
>> life, and 2.4 runs them directly [by default].
>>
>> rotatelogs currently doesn't do anything to block sigterm.  The
>> default ahndler for sigterm writes a short message to stderr, which is
>> the only reason I noticed.
>
> Maybe you could wrap rotatelogs in a script like:
>
> #!/bin/sh
> trap '' TERM
> /path/to/real/rotatelogs $@
>
> and then use:
> ErrorLog |$/path/to/my/rotatelogs.sh ...
>
> in httpd.conf?



-- 
Eric Covener
cove...@gmail.com

Re: httpd-trunk/modules/http2 gets a proxy

[NormW]

On 12/02/2016 9:13 PM, Stefan Eissing wrote:

Thanks. Added in r1729969.


Am 11.02.2016 um 21:52 schrieb NormW :





Thanks,
Norm

Re: httpd-trunk/modules/http2 gets a proxy

[NormW]

G/M And the start of yje weekend.
On 13/02/2016 4:06 AM, Rainer Jung wrote:

Am 12.02.2016 um 11:13 schrieb Stefan Eissing:

Thanks. Added in r1729969.


Am 11.02.2016 um 21:52 schrieb NormW :



The .txt extension is a bogus extension added by my mailer I assume.


I got confused. Which file now builds mod_proxy_http2 on Netware? I
can't find it. Shouldn't we also need a
modules/http2/NWGNUmod_proxy_http2 file?
Yes. I avoided digging further into that until the new NWGNUmakefile and 
NWGNUmod_http2 got added. Once they're playing correctly, then will come 
NWGNUproxy_htp2 (?) which will also get added to the list in the 
NWGNUmakefile.


NetWare has a file name limitation that needs some regard; while the 
file system of later OS releases supports 'long file names' on the disk
, every loadable module has an internal 8 char name IIRC, and no two 
nlm's with the same 8 char name can be loaded at the same time. IIRC the 
8 chars is the first 8 chars of the modules disk file name. (Anyone who 
knows better please jump in here.)

Regards,

Rainer


HTH,
Norm

Re: svn commit: r1729929 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h server/core.c

[William A Rowe Jr]

On Feb 12, 2016 04:45, "Yann Ylavic"  wrote:
>
> On Fri, Feb 12, 2016 at 10:49 AM, William A Rowe Jr 
wrote:
> > On Feb 12, 2016 2:24 AM, "Yann Ylavic"  wrote:
> >>
> >> I see this TODO about bitfield, but never seen it done in your
> >> commits, so I wonder where Rainer's warning comes from...
> >> Anyway, once backported (as you propose), we can hardly change it.

Well we simply can't reorder bitfields or add them in 2.4 anyways...

> > Precisely, it will NOT change in 2.4 and should not change, and is only
> > applicable to trunk.  I should have omitted from the initial commit.
> >
> > If we define this as int :2 and add a second int :2, none of the c
standards
> > promise that the initial 2-bit value maintains its previous alignment.
The
> > alignment is undefined.
>
> Indeed, and as such we can't make any promise about bits
> alignment/order wrt to the underlying int, and the user can't expect
> any either.

Therefore this is problematic for 2.4, and I added a comment to STATUS that
we drop that note if backporting the patch.  The note applies only to trunk.

> So I don't thing we should worry about compatibility of bitfields wrt
> added bits, the goal is to be able to add a new field without
> increasing the size of the struct (for something that requires only a
> few bits).

And that is the noble goal heading toward 2.next (3.0?) but it seems there
is no promise that adding one int foo:2 value following a previously
released int bar:2 member would preserve the bit alignment of bar across
all compilers?  That suggests possibly breaking our ABI contract on a
maintenance release.  So adding discrete bit fields seem very iffy, once we
tag a specific release branch.  (I can see safe exceptions if adding a
group of small ints together in a maintenance release, but you would want
to bookend that with a member of known alignment, an int or * or such.)

> Aside note: with an int:2 bitfield, the possible values are 0 (00), 1
> (01), -2 (10) and -1 (11), that may be surprising, although that fits
> your description of double_reverse.

You are only looking at 2's compliment architectures, httpd isn't Intel
specific :)  But we are promised 1..-1, while the fourth value is -2, or
-0, or 2, or NaN.  Not something to rely on, but we don't need a fourth
value here anyways.

> IMHO signed bitfields should be avoided, and I don't know if compilers
> are kind enough (nor allowed) to pack successive signed/unsigned
> bitfields, probably yes but otherwise we may lose extensibility of
> "int double_reverse:2" though...
> So we may prefer "unsigned int double_reverse:2" (and change the
> description) so that we can later add a single bit that equals 1 and
> not -1.

We've had good success, they get rearranged and optimized only when it is
convenient for us to break ABI.

Unsigned bitfields are sometimes more compact and get us one more value (we
cannot reliably use a -2 value in a 2 bit int as I mentioned above) but
this particular use doesn't seem problematic to optimize later (in
trunk)... Let's leave it as a full int to avoid future ABI alignment issues
for any 2.4 backport?