Re: [VOTE] Release Apache httpd 2.4.15 as GA

[William A Rowe Jr]

You are correct, however the "syntax" never illustrated this.

It seems we need two syntaxes, not a [target] optional argument.
On Jun 22, 2015 2:02 PM, "André Malo"  wrote:

> * Yann Ylavic wrote:
>
> > It seems that RedirectMatch isn't documented without the third (URL)
> > argument, unless in .
>
> Huh? Actually it is (or maybe I'm not getting something here). I checked at
> least back until 2.0.
>
> http://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirect clearly
> documents this.
>
> """
> Other status codes can be returned by giving the numeric status code as the
> value of status. If the status is between 300 and 399, the URL argument
> must be present. If the status is not between 300 and 399, the URL argument
> must be omitted.
> """
>
> http://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirectmatch refers
> to
> the above ("This directive is equivalent to Redirect").
>
> nd
> --
> "Solides und umfangreiches Buch"
>   -- aus einer Rezension
>
> 
>

Re: documentation issues for mod_authn_socache

[Helmut K. C. Tessarek]

On 2015-06-22 16:29, Nick Kew wrote:
> We don't know the platforms' defaults.  They're up to the packagers,
> and those sysops who make an active decision.

I don't understand. What do you mean by "this is up to the packagers"?

Is there a config option that decides this? If yes, let me ask this: what, if 
nothing is set?
Then there is no caching? What is used when someone calls the API 
ap_authn_cache_store? 

I'm sorry, but this makes no sense.
The defaults are in the code, aren't they? There should be something in the 
code like:

If on Linux and AuthnCacheSOCache not set, then use .

A default value is not something that is normaly chosen, and if it is, it 
should be at least explained how.

What about my 1st item? Misspelling of caching? How to fix it, who can fix it? 
Can I clone a repo
and create a pull request or do I have do work with svn?

-- 
regards Helmut K. C. Tessarek
lookup http://sks.pkqs.net for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness 
   await thee at its end.
*/

Re: documentation issues for mod_authn_socache

[Nick Kew]

On Mon, 22 Jun 2015 16:10:19 -0400
"Helmut K. C. Tessarek"  wrote:

> On 2015-06-17 18:03, Helmut K. C. Tessarek wrote:
> > Hello,
> > 
> > http://httpd.apache.org/docs/2.4/mod/mod_authn_socache.html
> > 
> > There are 2 things I want to mention:
> > 
> > 1) cacheing is not a word. It should be replaced with caching on the entire 
> > page
> > 2) AuthnCacheSOCache Directive:  If not set, your platform's default will 
> > be used.
> > 
> > There's no indication whatsoever what the platforms' defaults actually are.
> > 
> > Can someone please tell me what the platforms' defaults are?
> > 
> > I'm mostly interested in Linux and MacOSX, but a list would be nice in the 
> > docs.
> 
> 
> Does anyone have any input on this? Or is this the wrong list for doc issues?

We don't know the platforms' defaults.  They're up to the packagers,
and those sysops who make an active decision.

What you're asking is kind-of like asking us to concern ourselves
with the nuances of ext2/3/4 vs XFS vs JFS vs ZFS vs NTFS, etc.
We are agnostic.

-- 
Nick Kew

Re: documentation issues for mod_authn_socache

[Helmut K. C. Tessarek]

On 2015-06-17 18:03, Helmut K. C. Tessarek wrote:
> Hello,
> 
> http://httpd.apache.org/docs/2.4/mod/mod_authn_socache.html
> 
> There are 2 things I want to mention:
> 
> 1) cacheing is not a word. It should be replaced with caching on the entire 
> page
> 2) AuthnCacheSOCache Directive:  If not set, your platform's default will be 
> used.
> 
> There's no indication whatsoever what the platforms' defaults actually are.
> 
> Can someone please tell me what the platforms' defaults are?
> 
> I'm mostly interested in Linux and MacOSX, but a list would be nice in the 
> docs.


Does anyone have any input on this? Or is this the wrong list for doc issues?

-- 
regards Helmut K. C. Tessarek
lookup http://sks.pkqs.net for KeyID 0xC11F128D

/*
   Thou shalt not follow the NULL pointer for chaos and madness 
   await thee at its end.
*/

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[André Malo]

* Yann Ylavic wrote:

> It seems that RedirectMatch isn't documented without the third (URL)
> argument, unless in .

Huh? Actually it is (or maybe I'm not getting something here). I checked at 
least back until 2.0.

http://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirect clearly 
documents this.

"""
Other status codes can be returned by giving the numeric status code as the 
value of status. If the status is between 300 and 399, the URL argument 
must be present. If the status is not between 300 and 399, the URL argument 
must be omitted. 
"""

http://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirectmatch refers to 
the above ("This directive is equivalent to Redirect").

nd
-- 
"Solides und umfangreiches Buch"
  -- aus einer Rezension

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[Yann Ylavic]

Some tests added for framework in r1686886.

These cover:
Redirect 403 /forbidden
RedirectMatch 403 /f+

  Redirect 403

and should address the 2.4.13-15 regression.

I also changed the minimum version activating the expr tests
(Graham's), from 2.5 to 2.4.15.


On Mon, Jun 22, 2015 at 4:32 PM, Jim Jagielski  wrote:
> Agreed. We should also, everytime we catch something like this,
> add a test-case to the perl test framework to ensure we don't trip
> over it again :)
>
>> On Jun 22, 2015, at 8:24 AM, Rainer Jung  wrote:
>>
>> Am 22.06.2015 um 14:04 schrieb Jeff Trawick:
>>> On Mon, Jun 22, 2015 at 8:02 AM, Jim Jagielski >> > wrote:
>>>
>>>Seems that 3rd time was NOT the charm.
>>>
>>>Due to the regression I am canceling this VOTE.
>>>
>>>Let's patch 2.4.16-dev ASAP to handle this and I will T&R 2.4.16
>>>forthwith.
>>>
>>>
>>> Thanks, Jim!  We'll get through this eventually :)
>>>
>>> (And thanks Steffen and Reindl too!)
>>
>> +1 to both statements.
>>
>> My test went threw nicely, but due to the problem with the RedirectMatch I 
>> would have also voted -1.
>>
>> It is good we have those additional testers in the loop.
>>
>> Thanks
>>
>> Rainer
>>
>

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[William A Rowe Jr]

A sort of unusual case though, first fix is a docs patch, then a test case
for the newly-documented 16 year old behavior :) +1 to the collected
feedback and plan.
On Jun 22, 2015 9:32 AM, "Jim Jagielski"  wrote:

> Agreed. We should also, everytime we catch something like this,
> add a test-case to the perl test framework to ensure we don't trip
> over it again :)
>
> > On Jun 22, 2015, at 8:24 AM, Rainer Jung 
> wrote:
> >
> > Am 22.06.2015 um 14:04 schrieb Jeff Trawick:
> >> On Mon, Jun 22, 2015 at 8:02 AM, Jim Jagielski  >> > wrote:
> >>
> >>Seems that 3rd time was NOT the charm.
> >>
> >>Due to the regression I am canceling this VOTE.
> >>
> >>Let's patch 2.4.16-dev ASAP to handle this and I will T&R 2.4.16
> >>forthwith.
> >>
> >>
> >> Thanks, Jim!  We'll get through this eventually :)
> >>
> >> (And thanks Steffen and Reindl too!)
> >
> > +1 to both statements.
> >
> > My test went threw nicely, but due to the problem with the RedirectMatch
> I would have also voted -1.
> >
> > It is good we have those additional testers in the loop.
> >
> > Thanks
> >
> > Rainer
> >
>
>

Re: Next release of mod_fcgid

[Mario Brandt]

r1604123: Lower log "graceful kill fail, sending SIGKILL" level to
DEBUG on Windows. PR 54597.
and
r16041237: Follow up to r1604123: make it compile.

Cheers
Mario

On 22 June 2015 at 16:59, Jeff Trawick  wrote:
> On Mon, Jun 22, 2015 at 10:14 AM, Mario Brandt  wrote:
>>
>> Hi,
>>
>> the last release of mod_fcgid was been a long while.
>>
>> There was an important bugfix on windows side in June last year.
>>
>> Is there anyone willing to tag and release a new version?
>>
>
> There's nothing in CHANGES.  What was it?
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>

Re: Next release of mod_fcgid

[Jeff Trawick]

On Mon, Jun 22, 2015 at 10:14 AM, Mario Brandt  wrote:

> Hi,
>
> the last release of mod_fcgid was been a long while.
>
> There was an important bugfix on windows side in June last year.
>
> Is there anyone willing to tag and release a new version?
>
>
There's nothing in CHANGES.  What was it?

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[Jim Jagielski]

Agreed. We should also, everytime we catch something like this,
add a test-case to the perl test framework to ensure we don't trip
over it again :)

> On Jun 22, 2015, at 8:24 AM, Rainer Jung  wrote:
> 
> Am 22.06.2015 um 14:04 schrieb Jeff Trawick:
>> On Mon, Jun 22, 2015 at 8:02 AM, Jim Jagielski > > wrote:
>> 
>>Seems that 3rd time was NOT the charm.
>> 
>>Due to the regression I am canceling this VOTE.
>> 
>>Let's patch 2.4.16-dev ASAP to handle this and I will T&R 2.4.16
>>forthwith.
>> 
>> 
>> Thanks, Jim!  We'll get through this eventually :)
>> 
>> (And thanks Steffen and Reindl too!)
> 
> +1 to both statements.
> 
> My test went threw nicely, but due to the problem with the RedirectMatch I 
> would have also voted -1.
> 
> It is good we have those additional testers in the loop.
> 
> Thanks
> 
> Rainer
> 

Next release of mod_fcgid

[Mario Brandt]

Hi,

the last release of mod_fcgid was been a long while.

There was an important bugfix on windows side in June last year.

Is there anyone willing to tag and release a new version?


Cheers
Mario

Re: module configs across (pseudo) connections

[Eric Covener]

Should probably note somewhere that mod_logio won't log meaningful
results for h2 connections (based on how it tracks at connection
level)

On Mon, Jun 22, 2015 at 8:48 AM, Stefan Eissing
 wrote:
> Eric, thanks for the help! When enabling mod_logio it became immediately 
> clear that mod_h2 wrongly prevented some pre_connection hooks to run. 
> mod_logio however expects its allocated module config to be there when a 
> request gets cleaned up... So, with v0.7.2 all pre_conn hooks are run again 
> and it is part of my test setup now.
>
> Which adds the issue about proper handling of module configurations in pseudo 
> connections. There seem to be two approaches:
> a) treat pseudo connections like real ones -> run all connection hooks
> b) treat them as "shadows" of the real connection -> copy module configs
>
> While a) is the least dangerous, it misses gives a false impression about the 
> properties of a connection. For example, mod_h2 currently copies over the 
> mod_ssl config, so that SSL variables are available during request processing 
> on pseudo connections. On the other hand, code is not really prepared for b) 
> since this means that many threads may operate on the same module config.
>
> So, mod_h2 now follow a) for now (with the exception of mod_ssl). A future 
> proposal for pseudo connections will need to reevaluate this.
>
> Cheers,
>Stefan
>
>> Am 22.06.2015 um 14:23 schrieb Eric Covener :
>>
>> On Mon, Jun 22, 2015 at 7:38 AM, Stefan Eissing
>>  wrote:
>>> Thanks, now I see what you mean. What I do not understand:
>>> - why is this EOR processed too early?
>>
>> Usually it is at the end of a brigade and doesn't get cleaned up until
>> all of the data is written. But the copy and delete causes the cleanup
>> to run while you're iterating over the brigade to copy it in advance
>> of writing.
>>
>>> - what is causing the SegFault in the ap_run_log_transaction()
>>
>> I don't know. I would have guessed running it early would only impact
>> something later.
>>
>>> - and why am I seeing no errors on my system. Is this a configuration issue 
>>> with logging?
>>
>> Looks like you figured this out  -- must have mod_logio plus its %B or
>> whatever in your LogFormat.
>
> bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
>
>
>



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

module configs across (pseudo) connections

[Stefan Eissing]

Eric, thanks for the help! When enabling mod_logio it became immediately clear 
that mod_h2 wrongly prevented some pre_connection hooks to run. mod_logio 
however expects its allocated module config to be there when a request gets 
cleaned up... So, with v0.7.2 all pre_conn hooks are run again and it is part 
of my test setup now.

Which adds the issue about proper handling of module configurations in pseudo 
connections. There seem to be two approaches:
a) treat pseudo connections like real ones -> run all connection hooks 
b) treat them as "shadows" of the real connection -> copy module configs

While a) is the least dangerous, it misses gives a false impression about the 
properties of a connection. For example, mod_h2 currently copies over the 
mod_ssl config, so that SSL variables are available during request processing 
on pseudo connections. On the other hand, code is not really prepared for b) 
since this means that many threads may operate on the same module config.

So, mod_h2 now follow a) for now (with the exception of mod_ssl). A future 
proposal for pseudo connections will need to reevaluate this.

Cheers,
   Stefan

> Am 22.06.2015 um 14:23 schrieb Eric Covener :
> 
> On Mon, Jun 22, 2015 at 7:38 AM, Stefan Eissing
>  wrote:
>> Thanks, now I see what you mean. What I do not understand:
>> - why is this EOR processed too early?
> 
> Usually it is at the end of a brigade and doesn't get cleaned up until
> all of the data is written. But the copy and delete causes the cleanup
> to run while you're iterating over the brigade to copy it in advance
> of writing.
> 
>> - what is causing the SegFault in the ap_run_log_transaction()
> 
> I don't know. I would have guessed running it early would only impact
> something later.
> 
>> - and why am I seeing no errors on my system. Is this a configuration issue 
>> with logging?
> 
> Looks like you figured this out  -- must have mod_logio plus its %B or
> whatever in your LogFormat.

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[Rainer Jung]

Am 22.06.2015 um 14:04 schrieb Jeff Trawick:

On Mon, Jun 22, 2015 at 8:02 AM, Jim Jagielski mailto:j...@jagunet.com>> wrote:

Seems that 3rd time was NOT the charm.

Due to the regression I am canceling this VOTE.

Let's patch 2.4.16-dev ASAP to handle this and I will T&R 2.4.16
forthwith.


Thanks, Jim!  We'll get through this eventually :)

(And thanks Steffen and Reindl too!)


+1 to both statements.

My test went threw nicely, but due to the problem with the RedirectMatch 
I would have also voted -1.


It is good we have those additional testers in the loop.

Thanks

Rainer

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[Eric Covener]

On Mon, Jun 22, 2015 at 4:50 AM, Plüm, Rüdiger, Vodafone Group
 wrote:
> -1 from me as well on the release. Looks like we are a little bit out of luck 
> with 2.4.x releases recently :-).


I'll show some uncharacteristic optimism -- in a way we have been very
lucky to catch both issues during voting :)

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

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[Jeff Trawick]

On Mon, Jun 22, 2015 at 8:02 AM, Jim Jagielski  wrote:

> Seems that 3rd time was NOT the charm.
>
> Due to the regression I am canceling this VOTE.
>
> Let's patch 2.4.16-dev ASAP to handle this and I will T&R 2.4.16
> forthwith.
>

Thanks, Jim!  We'll get through this eventually :)

(And thanks Steffen and Reindl too!)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[Jim Jagielski]

Seems that 3rd time was NOT the charm.

Due to the regression I am canceling this VOTE.

Let's patch 2.4.16-dev ASAP to handle this and I will T&R 2.4.16
forthwith.

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[Jim Jagielski]

OK...

+1:
  o OSX 10.10.3, Xcode 6.3.2: x86_64
  o FreeBSD 9.4, 10.1: x86_64
  o CentOS 6.6, 7: x86_64

> On Jun 19, 2015, at 12:50 PM, Jim Jagielski  wrote:
> 
> The pre-release test tarballs for Apache httpd 2.4.15 can be found
> at the usual place:
> 
>   http://httpd.apache.org/dev/dist/
> 
> I'm calling a VOTE on releasing these as Apache httpd 2.4.15 GA.
> 
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
> 
> Vote will last the normal 72 hrs.
> 
> NOTE: The *-deps are only there for convenience.
> 
> Thx!
> 
> PS: Hopefully, 3rd time's the charm!

Re: buckets across threads - question

[Graham Leggett]

On 22 Jun 2015, at 10:07 AM, Stefan Eissing  
wrote:

> Sort answer: no.
> Re issue 28: I will look into this more today. I was able to generate a 
> segfault on connection shutdown on Friday and work on a fix.
> 
> Longer version re buckets: 
> - even though buckets for a request are created inside a single worker 
> thread, they are mutated/split/placed on free list upon processing down the 
> main connection. Which then all affects their bucket_alloc_t from several 
> threads. Especially on longer response bodies, 
> - since there are no function pointers for bucket_alloc_t, it is not obvious 
> to me how one would replace them with another implementation.
> - what can be added are, of course, new bucket implementations. Maybe there 
> is an approach to move the data itself without copying more than once. With a 
> clever handling of file buckets, maybe no copying at all.
> 
> Otherwise, I am open to ideas.

The secret to all of this is the pool hierarchy - if a request is to be served 
by any thread in a pool of threads, then that request mustn’t ever contain 
memory allocated from a pool tied to a specific thread.

When mod_proxy learned how to do connection pooling there were subtle pool 
lifetime issues uncovered caused by the backend connections allocated from a 
connection pool being interfaced to the frontend connections per request. You 
have to get the pools 100% right.

Regards,
Graham
—

Re: buckets across threads - question

[Eric Covener]

On Mon, Jun 22, 2015 at 4:07 AM, Stefan Eissing
 wrote:
> Sort answer: no.
> Re issue 28: I will look into this more today. I was able to generate a 
> segfault on connection shutdown on Friday and work on a fix.
>
> Longer version re buckets:
> - even though buckets for a request are created inside a single worker 
> thread, they are mutated/split/placed on free list upon processing down the 
> main connection. Which then all affects their bucket_alloc_t from several 
> threads. Especially on longer response bodies,
> - since there are no function pointers for bucket_alloc_t, it is not obvious 
> to me how one would replace them with another implementation.
> - what can be added are, of course, new bucket implementations. Maybe there 
> is an approach to move the data itself without copying more than once. With a 
> clever handling of file buckets, maybe no copying at all.
>
> Otherwise, I am open to ideas.

I am afraid the change will not fix #28. In the backtrace for #28 an
EOR bucket is being deleted while the buckets in a brigade are being
copied to a new pool. That triggers all of the end of request
processing way too early.

I was naively thinking as a POC it would be possible to pmemdup the
conn_rec and create a new bucket allocator (when you create the faux
request_rec) If it worked, we'd want to find some way to get the same
result in the core.  If we continue to share one at the real
connection level, I think it needs an option of a mutex under h2.

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

Re: Redirect proposed fix (was: [VOTE] Release Apache httpd 2.4.15 as GA)

[Yann Ylavic]

On Mon, Jun 22, 2015 at 12:56 PM, Yann Ylavic  wrote:
>
> The attached patch enables expressions for  context only a
> redirect status.

*and* a redirect status.

Redirect proposed fix (was: [VOTE] Release Apache httpd 2.4.15 as GA)

[Yann Ylavic]

On Mon, Jun 22, 2015 at 12:26 PM, Yann Ylavic  wrote:
> On Mon, Jun 22, 2015 at 10:50 AM, Plüm, Rüdiger, Vodafone Group
>> @Yann: Wouldn't it make sense to check for cmd->path as well before we do 
>> the expression parsing stuff to ensure we are really in a  
>> section?
>
> Yes, that's where I wanted to go for a final version of the patch,
> since the comment (above that code) states: "we use the expression
> syntax assuming a path from the location".

The attached patch enables expressions for  context only a
redirect status.
I'll try to add tests in framework when I have little time...

> OTOH, I don't see why it would be limited to a  context...
> But try_redirect() uses per_dir_config only, so it's probably better
> to not change this for now, and handle module_config in a follow up
> (once 2.4.16 is out! :)
>
> AIUI though, we now accept the URL to be (possibly) an expression, but
> I don't understand why we need these new alias_dir_conf entries to
> handle that, can't we simply use a new expr field in the alias_entry
> (maybe with some heuristic to use a plain string if no real expression
> is used, for performances reasons if that matters), and thus preserve
> the 2.4.12 logic?
>
> Also, I think we should handle any non-redirect (custom) statuses like
> we do for HTTP_GONE (no third/second URL argument required nor
> relevent, depending on vhost/location context), and mention it in the
> doc :)
>
> So finally this makes me wonder if we'd better not revert the change
> for now (at least the Redirect* part since Alias* changes look good),
> and think more about the possible Redirect* uses.

I can't find a related bugzilla for the feature (not sold already :),
so either way for me, revert or something like the attached...

>
> Regards,
> Yann.


httpd-2.4.x-mod_alias-redirect_expr.patch
Description: application/download

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[Yann Ylavic]

On Mon, Jun 22, 2015 at 10:50 AM, Plüm, Rüdiger, Vodafone Group
 wrote:
>
>
>> -Original Message-
>> From: Eric Covener [mailto:cove...@gmail.com]
>> Sent: Montag, 22. Juni 2015 01:08
>> To: Apache HTTP Server Development List
>> Subject: Re: [VOTE] Release Apache httpd 2.4.15 as GA
>>
>> On Sun, Jun 21, 2015 at 5:24 PM, William A Rowe Jr 
>> wrote:
>> > As this is not a regression from 2.4.13 or 2.4.14 candidates, it seems
>> to me
>> > we should ship.
>>
>> I am -1 for 2.4.15 with the regression.  The other candidates being
>> broken doesn't mitigate it much for me.
>
> +1 to Eric's comment and
> -1 from me as well on the release. Looks like we are a little bit out of luck 
> with 2.4.x releases recently :-).
> My proposal is to leave the vote open at most for 24 hours to see if anything 
> more comes up and then roll 2.4.16
> with the patch from Yann applied.
> @Yann: Wouldn't it make sense to check for cmd->path as well before we do the 
> expression parsing stuff to ensure we are really in a  section?
>
> So something like:
>
> @@ -270,7 +273,7 @@
>   * if we understand the first arg but have no second arg, we are dealing
>   * with a status like "GONE".
>   */
> -if (grokarg1 && arg2 && !arg3 && HTTP_GONE != status) {
> +if (grokarg1 > 0 && arg2 && !arg3 && cmd->path && HTTP_GONE != status) {
>  const char *expr_err = NULL;
>
>  dirconf->redirect =

Yes, that's where I wanted to go for a final version of the patch,
since the comment (above that code) states: "we use the expression
syntax assuming a path from the location".
OTOH, I don't see why it would be limited to a  context...
But try_redirect() uses per_dir_config only, so it's probably better
to not change this for now, and handle module_config in a follow up
(once 2.4.16 is out! :)

AIUI though, we now accept the URL to be (possibly) an expression, but
I don't understand why we need these new alias_dir_conf entries to
handle that, can't we simply use a new expr field in the alias_entry
(maybe with some heuristic to use a plain string if no real expression
is used, for performances reasons if that matters), and thus preserve
the 2.4.12 logic?

Also, I think we should handle any non-redirect (custom) statuses like
we do for HTTP_GONE (no third/second URL argument required nor
relevent, depending on vhost/location context), and mention it in the
doc :)

So finally this makes me wonder if we'd better not revert the change
for now (at least the Redirect* part since Alias* changes look good),
and think more about the possible Redirect* uses.

Regards,
Yann.

RE: [VOTE] Release Apache httpd 2.4.15 as GA

[Plüm , Rüdiger , Vodafone Group]

> -Original Message-
> From: Eric Covener [mailto:cove...@gmail.com]
> Sent: Montag, 22. Juni 2015 01:08
> To: Apache HTTP Server Development List
> Subject: Re: [VOTE] Release Apache httpd 2.4.15 as GA
> 
> On Sun, Jun 21, 2015 at 5:24 PM, William A Rowe Jr 
> wrote:
> > As this is not a regression from 2.4.13 or 2.4.14 candidates, it seems
> to me
> > we should ship.
> 
> I am -1 for 2.4.15 with the regression.  The other candidates being
> broken doesn't mitigate it much for me.

+1 to Eric's comment and
-1 from me as well on the release. Looks like we are a little bit out of luck 
with 2.4.x releases recently :-).
My proposal is to leave the vote open at most for 24 hours to see if anything 
more comes up and then roll 2.4.16
with the patch from Yann applied.
@Yann: Wouldn't it make sense to check for cmd->path as well before we do the 
expression parsing stuff to ensure we are really in a  section?

So something like:

@@ -270,7 +273,7 @@
  * if we understand the first arg but have no second arg, we are dealing
  * with a status like "GONE".
  */
-if (grokarg1 && arg2 && !arg3 && HTTP_GONE != status) {
+if (grokarg1 > 0 && arg2 && !arg3 && cmd->path && HTTP_GONE != status) {
 const char *expr_err = NULL;
 
 dirconf->redirect =

Regards

Rüdiger

Re: Using UPN from subjectAltName with SSLUserName

[Jan Pazdziora]

On Sun, Jun 21, 2015 at 08:55:02AM +0200, Kaspar Brand wrote:
> 
> The point with the otherName SAN type is that it's yet another bag of
> potentially arbitrary ASN.1 stuff, actually (not just simple strings, as
> is the case for rfc822Name or dNSName):
> 
>GeneralName ::= CHOICE {
> otherName   [0] OtherName,
> rfc822Name  [1] IA5String,
> dNSName [2] IA5String,
> x400Address [3] ORAddress,
> directoryName   [4] Name,
> ediPartyName[5] EDIPartyName,
> uniformResourceIdentifier   [6] IA5String,
> iPAddress   [7] OCTET STRING,
> registeredID[8] OBJECT IDENTIFIER }
> 
>OtherName ::= SEQUENCE {
> type-idOBJECT IDENTIFIER,
> value  [0] EXPLICIT ANY DEFINED BY type-id }
> ^^
> 
> (See RFC 7299 section 3.14 for the otherName forms defined by the PKIX
> WG in the past.)
> 
> While Microsoft's UPN happens to be a very simple case (the value is
> just a bare UTF8String here), this need not be true for other forms
> of otherName.
> 
> Adding support for msUPN seems useful, but it's really something which
> needs special-case coding in ssl_util_ssl.c:modssl_X509_getSAN(). I
> suggest using SSL_{CLIENT,SERVER}_SAN_OTHER_msUPN_* for the variable
> name(s), to make it clear that it's a subjectAltName entry of type
> otherName. Then, in the code for GEN_OTHERNAME, specifically look for
> this otherName form via "NID_ms_upn" - as only in this case, you
> can be sure to expect a simple UTF8String in otherName->value
> (strongSwan's openssl_x509.c might be a source of inspiration for coding
> this).
> 
> Note that for exposing the msUPN variables with StdEnvVars, you also
> need to adapt ssl_engine_vars.c:modssl_var_extract_san_entries().

Thank you for the analysis.

Please find a new patch attached which I hope covers all the
parts you've outlined, for SSL_CLIENT_SAN_OTHER_msUPN_*.

Yours,

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
Index: docs/manual/mod/mod_ssl.xml
===
--- docs/manual/mod/mod_ssl.xml (revision 1686805)
+++ docs/manual/mod/mod_ssl.xml (working copy)
@@ -77,6 +77,7 @@
 SSL_CLIENT_S_DN_x509 string
Component of client's Subject DN
 SSL_CLIENT_SAN_Email_n string  
Client certificate's subjectAltName extension entries of type 
rfc822Name
 SSL_CLIENT_SAN_DNS_n string
Client certificate's subjectAltName extension entries of type 
dNSName
+SSL_CLIENT_SAN_OTHER_msUPN_n 
stringClient certificate's subjectAltName extension entries of 
type otherName with Microsoft Universal Principal Name (OID 
1.3.6.1.4.1.311.20.2.3)
 SSL_CLIENT_I_DN   string
Issuer DN of client's certificate
 SSL_CLIENT_I_DN_x509 string
Component of client's Issuer DN
 SSL_CLIENT_V_STARTstring
Validity of client's certificate (start time)
Index: modules/ssl/ssl_engine_vars.c
===
--- modules/ssl/ssl_engine_vars.c   (revision 1686805)
+++ modules/ssl/ssl_engine_vars.c   (working copy)
@@ -674,6 +674,10 @@
 type = GEN_DNS;
 var += 4;
 }
+else if (strcEQn(var, "OTHER_msUPN_", 12)) {
+type = GEN_OTHERNAME;
+var += 12;
+}
 else
 return NULL;
 
@@ -1050,6 +1054,9 @@
 if (modssl_X509_getSAN(p, xs, GEN_DNS, -1, &entries)) {
 extract_san_array(t, "SSL_CLIENT_SAN_DNS", entries, p);
 }
+if (modssl_X509_getSAN(p, xs, GEN_OTHERNAME, -1, &entries)) {
+extract_san_array(t, "SSL_CLIENT_SAN_OTHER_msUPN", entries, p);
+}
 X509_free(xs);
 }
 }
Index: modules/ssl/ssl_util_ssl.c
===
--- modules/ssl/ssl_util_ssl.c  (revision 1686805)
+++ modules/ssl/ssl_util_ssl.c  (working copy)
@@ -258,6 +258,7 @@
  * of the n-th occurrence of that type only. Currently supported types:
  * GEN_EMAIL (rfc822Name)
  * GEN_DNS (dNSName)
+ * GEN_OTHERNAME (otherName for UPN)
  */
 BOOL modssl_X509_getSAN(apr_pool_t *p, X509 *x509, int type, int idx,
 apr_array_header_t **entries)
@@ -287,10 +288,18 @@
 APR_ARRAY_PUSH(*entries, const char *) = utf8str;
 }
 break;
+case GEN_OTHERNAME:
+if (name->d.otherName && name->d.otherName->value
+&& OBJ_obj2nid(name->d.otherName->type_id) == 
NID_ms_upn) {
+utf8str = asn1_string_to_utf8(p, 
name->d.otherName->value->value.asn1_string);
+if (utf8str) {
+ 

Re: buckets across threads - question

[Stefan Eissing]

Sort answer: no.
Re issue 28: I will look into this more today. I was able to generate a 
segfault on connection shutdown on Friday and work on a fix.

Longer version re buckets: 
- even though buckets for a request are created inside a single worker thread, 
they are mutated/split/placed on free list upon processing down the main 
connection. Which then all affects their bucket_alloc_t from several threads. 
Especially on longer response bodies, 
- since there are no function pointers for bucket_alloc_t, it is not obvious to 
me how one would replace them with another implementation.
- what can be added are, of course, new bucket implementations. Maybe there is 
an approach to move the data itself without copying more than once. With a 
clever handling of file buckets, maybe no copying at all.

Otherwise, I am open to ideas.

//Stefan

> Am 21.06.2015 um 17:07 schrieb Eric Covener :
> 
> re: https://github.com/icing/mod_h2/issues/28 has this design further evolved?
> 
> Is there a way to make the deep copy un-necessary by injecting your
> own bucket_alloc created with a pool with a threadsafe allocator very
> early?  It seems like all of the buckets are created in the h2 thread
> after you've had a chance to manipulate stuff.
> 
> 
> 
> On Tue, Mar 31, 2015 at 2:57 PM, Stefan Eissing
>  wrote:
>> Thanks, Jim!
>> 
>> 
>> 
>>> Am 31.03.2015 um 19:29 schrieb Jim Jagielski :
>>> 
>>> What I did is used the alpn patch as a guide and updated trunk
>>> to add the functionality:
>>> 
>>>   http://svn.apache.org/r1670397
>>> 
>>> I'll give it a few days to work out and then propose for a
>>> 2.4 backport.
>>> 
 On Mar 31, 2015, at 1:13 PM, Stefan Eissing  
 wrote:
 
 I think the old NPN patch is in trunk. The ALPN not AFAIK. I undertstand 
 there is a trunk first policy, but it'd be good to get it at least going 
 there... thanks.
 
 Stefan
 
 
 
 Am 31.03.2015 um 18:22 schrieb Jim Jagielski :
 
>> 
>> PS. As a small quid-pro-quo and because you were asking about a possibly 
>> 2.4.13: there has so far not been a volunteer to integrate the ALPN 
>> patch I adapted from mod_spdy. It would be great if someone could take a 
>> look at it. It is the biggest obstacle so far for experimenters (early 
>> sufferers) of mod_h2 and it would be very nice to have it out of the way.
> 
> I'll take a look. It's not currently in trunk, is that right?
>>> 
> 
> 
> 
> -- 
> Eric Covener
> cove...@gmail.com

bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782