Re: svn commit: r1836638 - /httpd/httpd/trunk/docs/manual/expr.xml

[André Malo]

* cove...@apache.org wrote:

> Author: covener
> Date: Wed Jul 25 14:46:33 2018
> New Revision: 1836638
>
> URL: http://svn.apache.org/viewvc?rev=1836638&view=rev
> Log:
> add 2 conditional logging examples
>
>
> +# Conditional logging
> +CustomLog logs/access-errors.log common “expr=%{REQUEST_STATUS} >=
> 400” +CustomLog logs/access-errors-specific.log common
> “expr=%{REQUEST_STATUS} -in {'405','410'}" +

Yuck. This is certainly not valid httpd.conf :-) Looks like fancy quotes 
from here. Please use boring quotes for pastability.

Cheers,
-- 
> Rätselnd, was ein Anthroposoph mit Unterwerfung zu tun hat...

[...] Dieses Wort gibt so viele Stellen für einen Spelling Flame her, und
Du gönnst einem keine einzige.-- Jean Claude und David Kastrup in dtl

Re: svn commit: r25871 - /release/httpd/docs/

[André Malo]

On Mittwoch, 21. März 2018 23:33:49 CET Daniel Ruggeri wrote:
> Is this something I could do as part of the push to the dist release
> mirrors? I have a script that handles the tarballs and doap updates so
> far. I'm also working on one that will also gather details and prep
> announcements if we should push these updates at that time.

It's certainly possible. The tarballs are easy. The PDF file needs a working 
tex installation (including pdflatex) - and in case something goes wrong 
some oversight.
The CHM files are a PITA, because the chm compiler needs a localized 
environment for each language (see build.sh -p). For me this means, 
rebooting a virtualbox with Windows for an hour or two. This is why I wait 
until we get a vote until I start building them :-)

It should be automatable in general, but I don't know how (I've got the 
windows + virtualbox more or less only for that purpose).

Cheers,

> > -Original Message-
> > From: n...@apache.org 
> > Sent: Wednesday, March 21, 2018 4:23 PM
> > To: c...@httpd.apache.org
> > Subject: svn commit: r25871 - /release/httpd/docs/
> > 
> > Author: nd
> > Date: Wed Mar 21 21:23:26 2018
> > New Revision: 25871
> > 
> > Log:
> > add static docs for 2.4.33 and update the build tools
> > 
[...]

-- 
Gib' mal folgendes in die Kommandozeile ein (und einen Moment warten):

net send localhost "Buuuh!"
Na, erschreckt?  -- Markus Becker in mpdsh

Re: svn commit: r1825373 - in /httpd/httpd/trunk/docs: man/ctlogconfig.8 manual/style/build.properties

[André Malo]

* Yann Ylavic wrote:

> On Mon, Feb 26, 2018 at 3:10 PM,   wrote:
> > +..
>
> oO
>
> For those who read the matrix? :)

However that happened... I just rebuilt it and it looks fine. Did you do 
anything special with that file, minfrin?

Cheers,
-- 
> [...] weiß jemand zufällig, was der Tag DIV ausgeschrieben bedeutet?
DIVerses. Benannt nach all dem unstrukturierten Zeug, was die Leute da
so reinpacken und dann absolut positionieren ...
   -- Florian Hartig und Lars Kasper in dciwam

Re: svn commit: r1793940 - in /httpd/docs-build/trunk: deps.xml lib/allmodules.pl

[André Malo]

* Jacob Champion wrote:

> [crossposting dev@ and docs@]
>
> On 05/04/2017 04:55 PM, jchamp...@apache.org wrote:
> > Author: jchampion
> > Date: Thu May  4 23:55:48 2017
> > New Revision: 1793940
> >
> > URL: http://svn.apache.org/viewvc?rev=1793940&view=rev
> > Log:
> > override index: add deps and exclude from all-modules list
>
> I found it a little weird that the XSLT dependencies aren't part of the
> httpd project, but exist in a separate repo... it doesn't seem like
> 2.x.y and trunk should be required to have the same dependency graph, or
> even the same processing scripts. And anyone who forgets to do an `svn
> up` in their build directory is likely to break things after my commits
> today.

Well... It was a split-project back then (in CVS even... :-)). I'm also not 
sure we want all those jar files and stuff in the main repo. Most people 
neither use nor need it.

Note that once the changes are finalized, you can run `build tools` and upload 
the package to dist/docs

IMHO as long as we can maintain it as a single toolset, we should keep it that 
way (we can also change behaviour based on the version property).

Cheers,
-- 
"Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III"

Im Westen was neues: 

Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in

[André Malo]

* William A Rowe Jr wrote:

> Please re-validate your assumptions before we proceed with this
> discussion. I'll be interested in your findings.

I did. I've decided to drop out of that "discussion".

Cheers,

Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in

[André Malo]

* William A Rowe Jr wrote:

> On Tue, Apr 18, 2017 at 3:56 PM, André Malo  wrote:
> > * wr...@apache.org wrote:
> >> Author: wrowe
> >> Date: Tue Apr 18 16:25:03 2017
> >> New Revision: 1791807
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1791807&view=rev
> >> Log:
> >> KISS: RemoveType is a simpler fix for .tr
> >
> > I seem to remember, that removetype does not override mime.types (only
> > addtype entries). But I might be wrong (and did not check now).
>
> I checked this in 2.4.x-dev branch, chrome could have lied, of course.

Hmm.
Ok, I looked it up. It was changed in 2.3.3. :-)

>
> >> explain .da files; order our
> >> LanguagePriority by a first-order comparison and drop negligable
> >> translations from our ordered priority preference list entirely.
> >
> > I don't see what problem that's supposed to solve. On the contrary,
> > since the configured negotiation happens per file [1], removing
> > languages, we do provide somewhere does not make sense at all.
>
> I'm not able to parse your thought here... let me clarify, and then
> please clarify your objection.
>
> The question of language priority is strictly one of the accuracy of one
> language variant over another.
>
> That question is largely answered by the browser, given three languages;
> fr q=1 en q=.8 ru q=.2 it says that this guest of your website is fluent
> in French, will comprehend English reasonably well, and can stumble
> through some Russian. So if the French can be served, we will serve it,
> and as all documents exist in English, we will fall back on that.
>
> The question isn't answered if this is a client with no matching
> languages, if only Estonian is given as a preferred language, we would
> normally serve a list of possible documents. That's foolish so we
> force-override with some sensible choice and an option to toggle between
> languages on every page.
>
> Where we find et q=1 fr q=.5 es q=.5 ... they will be equally comfortable
> with either French, or Spanish, since Estonian isn't available. Now which
> do we serve? That is where my edit comes in.
>
> The answer is invariably English because that is the source language.

Ehm? How is the whole negotation mechanism about the source language? Why 
would it care?

> Where equal-weight is given and we have two translations other than
> English to automatically fulfill, it must be the more relevant one.

Why? if it would matter, it would be given differently by the browser. Who 
are we to decide anyway? I would probably pick the first one and it might 
even be in accordance to the RFC (would need to check).

> We can't practically do this on a document-by-document basis

See above. Luckily there's no need to.

> so what is 
> your suggestion for prioritizing the most trustworthy (on our terms)
> translation where the user-agent refuses to give one or the other a
> higher priority?

My argument is about something completely different. It's not about the 
collection of documents, it about you come to the start page, could 
theoretically automatically see the danish variant but don't because it's 
not listed at all.

That's what you just killed, I think.

For the collection as a whole we added the prefer-language variable, which 
we use to give the user a simple choice between her preferred language and 
the source language (fallback).

Cheers,
-- 
sub the($){+shift} sub answer (){ord q
[* It is always 42! *]   }
   print the answer
# André Malo # http://pub.perlig.de/ #

Re: svn commit: r1791807 - /httpd/httpd/trunk/docs/conf/extra/httpd-manual.conf.in

[André Malo]

* wr...@apache.org wrote:

> Author: wrowe
> Date: Tue Apr 18 16:25:03 2017
> New Revision: 1791807
>
> URL: http://svn.apache.org/viewvc?rev=1791807&view=rev
> Log:
> KISS: RemoveType is a simpler fix for .tr

I seem to remember, that removetype does not override mime.types (only 
addtype entries). But I might be wrong (and did not check now).

> explain .da files; order our 
> LanguagePriority by a first-order comparison and drop negligable
> translations from our ordered priority preference list entirely.

I don't see what problem that's supposed to solve. On the contrary, since 
the configured negotiation happens per file [1], removing languages, we do 
provide somewhere does not make sense at all.

Please revert.

[1] if you do not specifically select a preferred language via the path 
magic

Cheers,
-- 
Treat your password like your toothbrush. Don't let anybody else
use it, and get a new one every six months.  -- Clifford Stoll

(found in ssl_engine_pphrase.c)

Re: svn commit: r1750681 - in /httpd/httpd/branches/2.4.x: STATUS docs/manual/mod/mod_proxy_http2.html docs/manual/mod/mod_proxy_http2.html.en docs/manual/mod/mod_proxy_http2.xml.meta

[André Malo]

* j...@apache.org wrote:

> Author: jim
> Date: Wed Jun 29 17:28:53 2016
> New Revision: 1750681
>
> URL: http://svn.apache.org/viewvc?rev=1750681&view=rev
> Log:
> vote.
> Required since w/o this patch, previous build fail (no lbmethods)
>
> Removed:
> httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_http2.html
> httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_http2.html.en
> httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_http2.xml.meta

Huh?

nd
-- 
Das einzige, das einen Gebäudekollaps (oder auch einen
thermonuklearen Krieg) unbeschadet übersteht, sind Kakerlaken
und AOL-CDs.
  -- Bastian Lipp in dcsm

Re: svn commit: r1732029 - in /httpd/httpd/branches/2.2.x/docs/manual: ./ style/ style/lang/ style/xsl/

[André Malo]

* Luca Toscano wrote:

> Hi André!
>
> 2016-02-24 11:44 GMT+01:00 André Malo :
> > Is there a reason why you reset the banner translations?
>
> I changed the banner's wording a bit for this use case. From (taking 2.0
> one as reference):
>
> "This document refers to the 2.0 version of Apache httpd, which is no
> longer maintained. Upgrade, and refer to the current version of httpd
> instead, documented at:"
>
> to
>
> "This document refers to a legacy release (2.2) of Apache httpd. The active
> release (2.4) is documented here. If you have not already upgraded, please
> follow this link for more information."
>
>
> The 2.2 use case seems a bit different because it is legacy but still
> supported, so I thought to add a more conservative message. I consequently
> changed the translated banners to avoid confusion, but we might just decide
> to go for the "no longer maintained" original option to keep all the
> translations.

Ah, didn't get that. Thanks!

> Let me know if you want me to amend my change, or just rollback it entirely
> to study a better solution.

Nah, it's just fine ;)


Cheers,
nd
-- 
Already I've seen people (really!) write web URLs in the form:
http:\\some.site.somewhere
[...] How soon until greengrocers start writing "apples $1\pound"
or something?   -- Joona I Palaste in clc

Re: svn commit: r1732029 - in /httpd/httpd/branches/2.2.x/docs/manual: ./ style/ style/lang/ style/xsl/

[André Malo]

Hi,

* elu...@apache.org wrote:

> Author: elukey
> Date: Wed Feb 24 07:28:24 2016
> New Revision: 1732029
>
> URL: http://svn.apache.org/viewvc?rev=1732029&view=rev
> Log:
> Added retirement banner to all the documentation pages to suggest the
> migration to 2.4

Is there a reason why you reset the banner translations?

Cheers,
nd
-- 
Winnetous Erbe: 

Re: svn commit: r1725339 - /httpd/httpd/trunk/docs/manual/index.xml.es

[André Malo]

* Mike Rumph wrote:

> Is there some reason why the license information is not translated into
> Spanish?

Yes. It would not have any legal power. There is no official translation of 
the apache license (AFAIK).

Cheers,
nd
-- 
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;

#  André Malo  #  http://pub.perlig.de  #

Re: [VOTE] Release Apache httpd 2.4.15 as GA

[André Malo]

* William A Rowe Jr wrote:

> On Mon, Jun 22, 2015 at 2:01 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.
>
> That's helpful, except that #redirectmatch does not point back to #redirect
> as authoritative over arguments.

*shrug* apparently I interpret "equivalent" differently (the part you left out 
of the quote), but whatever.

> We all now agree that the 2.4.12 and
> prior behavior should be preserved, but that doesn't remedy the
> documentation.

Well, we could copy it, if that makes you happy ;-)

nd
-- 
Das, was ich nicht kenne, spielt stückzahlmäßig *keine* Rolle.

   -- Helmut Schellong in dclc

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: *Match, RewriteRule POLA violation?

[André Malo]

* Jim Riggs wrote:

> > On 1 May 2015, at 10:52, André Malo  wrote:
> >
> > * Niklas Edmundsson wrote:
> >> On Thu, 30 Apr 2015, Yann Ylavic wrote:
> >>> On Thu, Apr 30, 2015 at 2:57 PM, Jim Riggs 
> >
> > wrote:
> >>>> Thanks, Yann. I remember looking at this code before. The question
> >>>> remains, though: Is it currently "wrong"? Does it need to be "fixed",
> >>>> or was this distinction made intentionally? Is there a specific use
> >>>> case that requires the regex-matching directives to not get
> >>>> slash-normalized URIs?
> >>>
> >>> I would like it to be fixed, non leading "/+" is equivalent to "/",
> >>> this would break very few (if any) cases IMHO, and may even unbreak
> >>> more ones .
> >>
> >> +1
> >>
> >> I would expect Location and LocationMatch using the same uri for
> >> comparison.
> >
> > Hmm, that assumption is wrong by definition. Location always matches a
> > prefix (a part of a parsed/unparsed url), while LocationMatch always
> > matches the complete URL.
>
> We need to be careful on that phrasing. LocationMatch *can* match the
> complete URL if it is anchored at both ends. By default, though, it will
> match anywhere in the URL if it is unanchored, and it can (with the '/+' we
> are discussing here) behave just like Location and match a prefix if it is
> only anchored at the beginning.

Well, yes, careful. It's actually the regex which is anchored, not the URL ;-)


> However, that documentation is actually not correct. This is not true: "For
> example,  would match the request URL /abc but not
> the request URL //abc." Based on all of my tests, the leading slash *is*
> collapsed in the *Match and RewriteRule directives. Subsequent slashes
> after the first are not.

It's probably too old.

> So, it is documented, but is there a compelling use case for this? When
> would someone actually need to match against the multiple slashes (unless
> it's some really strange hack someone has implemented)? The only thing I
> can think of is that maybe you want to force a redirect to remove multiple
> slashes, but couldn't a directive in mod_alias(?) maybe handle that if
> deemed necessary?

As said, I'd concur for fixing LocationMatch, but we might consider leaving it 
as-is for RewriteRule (and document it better), because we may want to give 
the swiss-knife-user something to work on.

Cheers,
nd
-- 
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~  # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord(  # André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see;  #  http://pub.perlig.de/ ;

Re: *Match, RewriteRule POLA violation?

[André Malo]

* Niklas Edmundsson wrote:

> On Thu, 30 Apr 2015, Yann Ylavic wrote:
> > On Thu, Apr 30, 2015 at 2:57 PM, Jim Riggs  
wrote:
> >> Thanks, Yann. I remember looking at this code before. The question
> >> remains, though: Is it currently "wrong"? Does it need to be "fixed",
> >> or was this distinction made intentionally? Is there a specific use
> >> case that requires the regex-matching directives to not get
> >> slash-normalized URIs?
> >
> > I would like it to be fixed, non leading "/+" is equivalent to "/",
> > this would break very few (if any) cases IMHO, and may even unbreak
> > more ones .
>
> +1
>
> I would expect Location and LocationMatch using the same uri for
> comparison.

Hmm, that assumption is wrong by definition. Location always matches a 
prefix (a part of a parsed/unparsed url), while LocationMatch always 
matches the complete URL.

> I would actually go so far as the current state might 
> warrant a CVE for being a hidden security risk that might cause
> inadvertent information exposure.

It *is* documented right here, btw: 
http://httpd.apache.org/docs/2.4/mod/core.html#location

(found it, eventually...)

nd
-- 
"Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3)"
  -- aus einer Rezension

Re: *Match, RewriteRule POLA violation?

[André Malo]

* Jim Riggs wrote:

> This came up at ApacheCon a couple of weeks ago. I just took this knowledge
> for granted, as I have always accounted for it, but both Rich and Trawick
> were surprised. As I thought about it some more, it seems this may be a
> POLA violation. Thoughts? If we agree it should be fixed, I can make the
> bugz and make a patch.

I use /+ patterns all over the place (I even trained people to use them) and I 
was sure, it was documented, but I can't seem to find it, where I'd expect 
it. So, IMHO it just should be better documented. At least for something like 
mod_rewrite it should be possible to inspect the original uri (and possibly 
take some action).

nd

P.S.: had to look up "POLA" ;-)
-- 
Gefunden auf einer "Webdesigner"-Seite:
> Programmierung in HTML, XML, WML, CGI, FLASH <

# André Malo # http://pub.perlig.de/ #

Re: Run external RewriteMap program as non-root

[André Malo]

* Jan Kaluža wrote:

> Hi,
>
> currently, the External Rewriting Program (RewriteMap "prg:") is run as
> root. I would like to change it but I see three ways how to do it:
>
> 1. Execute it right after drop_privileges hook. This looks like best
> way, but I haven't found any hook which could be used for that (except
> drop_privileges with APR_HOOK_REALLY_LAST, which does not seem as proper
> place to me).
>
> 2. Execute it in child_init. This is done after drop_privileges, so the
> user/group is good. The "problem" here is that it would execute one
> rewrite program per child. Right now I'm not sure if it's really
> problem. It could be useful to have more instances of rewriting program
> to make its bottleneck lower.
>
> 3. Execute it where it is now (post_config), but set user/group using
> apr_procattr_t. So far I think this would duplicate the code of
> mod_unixd and would probably have to also handle the windows equivalent
> of that module (if there's any).

May be

4) Invoke suexec somehow

and

5) Let it drop the privileges by itself.

I actually tend to 5 :-)

nd
-- 
Winnetous Erbe: 

Re: replacing Date header

[André Malo]

* Tim Bannister wrote:

> On 17 Feb 2015, at 22:21, André Malo  wrote:
> > However, I always saw this Date header handling as a way to enforce RFC
> > compliance (e.g. to overwrite Date-headers in mod_asis handlers and
> > crappy backends). Wrong Date headers may have a huge impact, as I see
> > it. But then, maybe I'm overrating that.
>
> So maybe the logic should be to preserve a Date: header iff it is
> compliant with the relevant RFC? With this, modules that want a Date:
> header automatically added need only to ensure they don't assert an
> apparently valid Date header.

Hmm, which would be the current (!) server time in the correct format. We 
might need to define some epsilon time which is still acceptable or so.

... it's probably cheaper to keep it as it is right now ;-)

nd
-- 
Winnetous Erbe: <http://pub.perlig.de/books.html#apache2>

Re: replacing Date header

[André Malo]

* Eric Covener wrote:

> On Tue, Feb 17, 2015 at 4:05 PM, André Malo  wrote:
> >> There are lots of non-mod_proxy modules that act as a proxy of one
> >> sort or another -- shouldn't we just respect their date header if they
> >> issue one?
> >
> > Hmm, I'm actually wondering why. And which ones would that be?
>
> Java application servers like WebSphere and WebLogic provide Apache
> modules like this.  I don't know how to address the "why", I just want
> to remove the special treatment for mod_proxy / r->proxyreq and only
> set a Date if one wasn't provided by the handler.  The user I was
> working with didn't fully understand how how his software re-used the
> value in the Date header as sent in the handler.

Uhm, I have no real idea about those, but are they not integrated with the 
proxy framework? ajp?

However, I always saw this Date header handling as a way to enforce RFC 
compliance (e.g. to overwrite Date-headers in mod_asis handlers and crappy 
backends). Wrong Date headers may have a huge impact, as I see it.
But then, maybe I'm overrating that.

nd
-- 
s  s^saoaaaoaaoaaaom  a  alataa  aaoat  a  a
a maoaa a laoata  a  oia a o  a m a  o  alaoooat aaool aaoaa
matooololaaatoto  aaa o a  o ms;s;\s;s;g;y;s;:;s;y#mailto: #
 \51/\134\137| http://www.perlig.de #;print;# > n...@perlig.de

Re: replacing Date header

[André Malo]

* Eric Covener wrote:

> There are lots of non-mod_proxy modules that act as a proxy of one
> sort or another -- shouldn't we just respect their date header if they
> issue one?

Hmm, I'm actually wondering why. And which ones would that be?

nd
-- 
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join   #
 [ $japh =~ /{(.)}/] -> [0] => map $_ -> ()  #André Malo #
=> @japh;# http://www.perlig.de/ #

Re: [Patch] Simplifying mod_alias

[André Malo]

Hi,

I think, most of the directives are compatibility ones. IMHO the best way to 
handle a transition to a different configuration concept would be to 
introduce a new module (mod_alias_ng or mod_fs_map or so...) instead of 
patching the current one and producing a lot of anger (Alias* and Redirect* 
are often used in my experience, also in combination with proxy and rewrite 
stuff). Additionally this could serve as a kind of an A/B test to test your 
configuration (and see if people really like it, if anybody cares about 
that).

nd

* Graham Leggett wrote:

> On 27 Jan 2014, at 12:11 AM, GRAHAM LEGGETT  wrote:
> > A look at mod_alias shows it has 7 directives:
> >
> > • Alias
> > • AliasMatch
> > • Redirect
> > • RedirectMatch
> > • RedirectPermanent
> > • RedirectTemp
> > • ScriptAlias
> > • ScriptAliasMatch
> >
> > In theory we only need these three:
> >
> > • Alias
> > • Redirect
> > • ScriptAlias
> >
> > What I'm keen to do is enable expression support and deprecate all but
> > the above, with the following as the preferred configuration method
> > (same as the one used by ProxyPass):
> >
> > 
> > Alias /var/lib/bar
> > …stuff...
> > 
> >
> > or
> >
> > [^/]+)>
> > Alias /var/lib/%{env:MATCH_BAR}/baz
> > …stuff...
> > 
> >
> > In theory this would be faster as we would not be scanning the list of
> > Aliases followed by the list of Locations each time, and things get a
> > lot simpler to use.
>
> This patch implements the above.
>
> The idea is that the existing syntaxes remain unaltered (and can be
> deprecated in future), while we introduce new Location syntaxes with a
> single argument, like so:
>
> 
>   Alias /ftp/pub/image
> 
> [0-9]+)>
>   Alias /usr/local/apache/errors/%{env:MATCH_NUMBER}.html
> 
> 
>   Redirect permanent http://example.com/two
> 
> 
>   Redirect 303 http://example.com/other
> 
> [0-9]+)>
>   Redirect permanent http://example.com/errors/%{env:MATCH_NUMBER}.html
> 
> 
>   ScriptAlias /web/cgi-bin/
> 
> [0-9]+)>
>   ScriptAlias /web/cgi-bin/errors/%{env:MATCH_NUMBER}.cgi
> 
>
> Big win: three fewer reasons to use mod_rewrite (and maybe
> mod_vhost_alias).
>
> Regards,
> Graham
> —



-- 
"Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3)"
  -- aus einer Rezension

Re: [RFC] CGIPassHeader Authorization|Proxy-Authorization|...

[André Malo]

Hi,

only short notes from me. I'd appreciate such a directive very much. I 
think, allowing it in .htaccess won't hurt. I can't come up with a use 
case, where the person behind the script doesn't have access to the 
credentials anyway.

As for the passing right now, you don't need the whole mod_rewrite machinery 
for this:

SetEnvIf Authorization (.+) HTTP_AUTHORIZATION=$1

that's, what I've been using so far :)

nd

* Graham Dumpleton wrote:

> A few comments on this.
>
> The first is that mod_wsgi originally never allowed its
> WSGIPassAuthorization directive in a htaccess file, and then when it it
> did first allow it, it was only honoured if AuthConfig was allowed for
> that context.
>
> I kept having people who needed that ability when they had a htaccess
> file, but didn't have AuthConfig.
>
> One of the things that was pointed out was that if you have htaccess
> enabled, and mod_rewrite was being loaded into Apache, you could get
> access to the Authorization header anyway.
>
> RewriteEngine on
> RewriteBase /
> RewriteCond %{HTTP:Authorization}  ^(.*)
> RewriteRule ^(.*)$ $1 [e=HTTP_AUTHORIZATION:%1]
>
> In the end, since mod_wsgi arguably shouldn't ever be used in shared
> environments anyway, I ended up caving in and allowing
> WSGIPathAuthorization in htaccess to make it convenient for the more
> typical scenario that kept coming up.
>
> Now having the ability within mod_wsgi for a web application to handle
> authorisation this showed up a couple of problems in the
> ap_scan_script_header_err_core()
> function. This arose because the response data when it comes back from a
> mod_wsgi daemon process just users the CGI way of doing things and so
> used that function.
>
> The first problem was that when WWW-Authenticate headers came back in a
> response, the ap_scan_script_header_err_core() function would merge the
> values of multiple instances of such headers with a comma in between the
> values. As a result, a single header would get returned back to the HTTP
> client. As with Set-Cookie header, this would cause problems with some
> HTTP clients and they would fail due to the merging. More recent versions
> of mod_wsgi therefore no longer use ap_scan_script_header_err_core() and
> have had to duplicate what it does so as to prevent merging of
> WWW-Authenticate headers.
>
> The second problem was the size limitation on the values of the headers
> coming back from a CGI script. As is, the complete header name and value
> must fit within MAX_STRING_LEN (8192). If the size didn't fit under that,
> you would from memory get the cryptic error message of 'Premature end of
> script header'. In recent times, application such as OpenStack KeyStone
> have been generating values for the WWW-Authenticate header which are
> larger than MAX_STRING_LEN and so they were failing when used with
> mod_wsgi because of the use of ap_scan_script_header_err_core(). In
> recent versions of mod_wsgi, the buffer size used to read the header name
> and value defaults to 8192, but can be overridden through a configuration
> option to allow a larger value to come back.
>
> So irrespective of where you are going to allow this CGIPassHeader
> directive, you might want to look at these other two issues, and if not
> both, certainly the issue of WWW-Authenticate being merged as it will
> cause issues for some browsers if someone ends up passing back multiple
> WWW-Authenticate headers as I am told it can if it supports a choice of
> authentication schemes.
>
> Graham
>
> On 17 August 2014 06:16, Jeff Trawick  wrote:
> > This core directive would be used to modify the processing of
> > ap_add_common_vars() to pass through Authorization or
> > Proxy-Authorization as HTTP_foo.  (Nothing else is currently blocked,
> > so any other header name wouldn't make sense.)
> >
> > This directive would be configurable at the directory level, but not in
> > htaccess.
> >
> > Various mods (mod_fastcgi, mod_fcgid, mod_wsgi, etc.) have ways to pass
> > this information through; bug 56855 has a patch to add it to
> > mod_proxy_fcgi too.  With that patch in place, at least mod_proxy_scgi
> > in our tree still couldn't front an app that wants to handle Basic
> > auth.  It would be good to consolidate over time the code/documentation
> > around suppressing *Authorization.
> >
> > Some concerns: Processing it in ap_add_common_vars() is not finely
> > scoped to natural users of the data; e.g., mod_include and
> > mod_ext_filter would see it.  At the same time, not allowing it in
> > htaccess may negate its usefulness in some environments.
> >
> > Thoughts?
> >
> > --
> > Born in Roswell... married an alien...
> > http://emptyhammock.com/



-- 
>kann mir jemand sagen, was genau @-Domains sind?
Ein Mythos. Ein Werbetrick. Verarsche. Nenn es wie du willst...

 -- Alexandra Buss und Björn Höhrmann in dciwam

Re: Change of web site layout

[André Malo]

* Daniel Gruno wrote:

> > As a user, I'd like to see relevant information. It must be possible to
> > get the relevant information without javascript (yes!) and without
> > random clicking (what should I expect from a non-descriptive arrow-link
> > which feels like an adverstisement?).
>
> I disagree with the use of the word 'must' here, 'should' is a much
> nicer word to use when one has only personal preference behind ones
> css+noscript combo (identical comment further down, I write in reverse).

A page, where content is not reachable (also for search indexers), is 
useless. If you like "should" better, fine. We should not build such a 
thing.

I have similar problems (and I'm not the only one) with the recent 
python.org relaunch.
We have to try to be helpful, not fancy in the first place.

>
> > Which means, all maintained releases should be visible at once. That
> > has nothing to do with Apache, that's a simple observation, how people
> > look on software pages.
>
> A counter-observation is that a big wall of text, where everything looks
> the same, isn't preferable either.

Nobody says, that everything has to look the same. And that the whole text 
blob should be visible at once. But a release overview (Two current 
branches are not that much) would be fine.


> I have tried to counter that, but I 
> will gladly accept any proposals to add all the (non-EOL) releases to
> some form of matrix on the front page. I'm just not sure how to tackle
> it yet.

2.0 is EOL. So it's basically two boxes or something.

>
> > And yes, as an admin I may have only a text browser available if I want
> > to check the current security state of a software *on my server*. Shit
> > happens.
>
> Good thing this proposal works perfectly well with Lynx then.

I don't use lynx ;)


>
> > Anyway, here are some more comments based on a *quick* review. I find
> > the 72h timebox way too short for such a change, by the way, especially
> > over a weekend.
>
> It's not _over a weekend_, and I'm not trying to sneak in a change this
> big. If I wanted that, I would've JFDI'ed it and taken the flak. But I
> also don't want yet another 17(!) years of saying "hmm we should do
> something" and then not doing anything because we're too busy staring at
> our own navels.

Sorry for that, I messed up the days (it was shortly after midnight here).

> I asked that anyone object if they found something wrong 
> with a 72h lazy consensus, and you have objected, and I will naturally
> take that into account.

Fine. I think, it's wrong.


> We have a web site that screams "we don't care anymore!", and that makes
> me an angry pony. And sometimes angry ponies use lazy consensus because
> it seems like we are only a handful of people who really care enough. I
> am glad that you care, that makes another one of us.
>
> > (also a screenshot: )
>
> That's a matter of tweaking the CSS, although I hadn't imagined anyone
> visiting with less than 720p these days, so I hadn't tried what would
> happen if someone did. I will correct the styles to also work with very
> narrow screens.

Huh. The browser was 1016 pixels wide. So is the screenshot... How is that 
narrow and less than 720p?

>
> > - Don't fix the fonts to px size.
> > - The maint font (Libertine) is badly readable.
>
> I disagree, but we can probably find a font more suitable (or settle for
> Serif if all else fails)

So, you find it well-readable? Try reading the text in the screenshot.

> >   Also, the legal stuff should be reachable without Javascript anyway.
>
> As stated earlier, I find that to be a very...vague argument.

You might want to have a look at laws of certain countries (Germany is an 
example). Although they don't apply directly, mirroring might be an issue.


> Other than 
> actively choosing to disable JavaScript while retaining CSS styles, you
> won't find yourself in a situation where you can't use the navigation
> properly.

Which is the typical case (using noscript), though. It's easily possible to 
build it working that way. If bootstrap can't do that, we have to give it a 
boot.

(no pun intended)

>
> > - Once I activated JS, I immediatetly found the carousel autoscrolling
> >   annoying (the animation too, because it steals my time, but YMMV).
>
> That can be adjusted/disabled. I have changed it to 15 seconds per
> frame, up from 10 sec/frame. I'm interested in hearing what others think
> of this.

Yes, my answer was to all. I've just stated my thinkings here.

>
> > - A final version should remove external dependencies and all inline
> > style attributes. Also, unscoped style blocks within the body are
> > invalid HTML.
>
> Yes, I have that on my To-do list. I was initially more interested in 
> comments on the overall look and feel, and not so much whether it's
> valid HTML - those things can always be fixed, and any modern browser
> will work with it in any case.

Such an early state should not go to the CMS then.


>
> > - Bt

Re: Change of web site layout

[André Malo]

Hi,

* Daniel Gruno wrote:

> Hi there, dev@ people (and docs@ cc'ed),
>
> For some time now, a lot of us from the documentation team have been
> pondering on making our site, well, not so 1990s looking and unappealing.

+1 at the point.

>
> We've had some input from various people over time, and together with my
> own thoughts, I've come up with a new core template that I plan to
> submit to our CMS system if there aren't too many objections.
>
> A mockup front-page featuring this new design can be seen at
> http://httpd.apache.pw/ (please don't start browsing the entire site, IT
> DOES NOT WORK, it needs to be behind our CMS system to be pretty and
> useable).
>
> And yes, this new layout will feature some changes:
>
> - News are placed in a carousel to eliminate the 'wall of text' we
> currently have. RMs will have to get acquainted with how to change the
> news on the site (which shouldn't be difficult if you look at the source
> code, you will still be able to use the CMS to edit it)
> - The menu is now a top bar instead of a side bar
> - Some menu items have been grouped together differently than before
> - The 8 bit feather has been replaced with the 32 bit one.
> - It's not quite as...blue
>
> Now, before half the team starts complaining that this uses HTML5,
> JavaScript or CSS3, please bear in mind that *we are not the intended
> audience*. This is not - and should not be - about what we want, it's
> about what modern (non-lynx) users will find attractive or off-putting
> about a site.

That's a killer phrase. User typically find a site attractive, if they find 
their use cases served (properly). If it looks nice, the better, of course. 
If it wastes her time looking attractive, but not being helpful, it's just 
making her angry.

As a user, I'd like to see relevant information. It must be possible to get 
the relevant information without javascript (yes!) and without random 
clicking (what should I expect from a non-descriptive arrow-link which 
feels like an adverstisement?).
Which means, all maintained releases should be visible at once. That has 
nothing to do with Apache, that's a simple observation, how people look on 
software pages.

And yes, as an admin I may have only a text browser available if I want to 
check the current security state of a software *on my server*. Shit 
happens.

Anyway, here are some more comments based on a *quick* review. I find the 
72h timebox way too short for such a change, by the way, especially over a 
weekend.

(also a screenshot: )

- Don't fix the fonts to px size.
- The maint font (Libertine) is badly readable.
- the tagline is weirdly placed (see screenshot, made with a current 
  firefox)
- The carousel padding seems strange, too
- also, it's italic, that looks, like, 80s, sorry (as in: Text processing 
  software on my good old Atari ST :-)
- (Maybe the points above are due to freetype, but that's how it is.

- As said, all the technologies are fine, just make sure, it's usable 
  without it. An implementation could be to add real links to the dropdown 
  headings pointing to pages listing the submenus).

  Also, the legal stuff should be reachable without Javascript anyway.

- Once I activated JS, I immediatetly found the carousel autoscrolling 
  annoying (the animation too, because it steals my time, but YMMV).

- A final version should remove external dependencies and all inline style 
  attributes. Also, unscoped style blocks within the body are invalid HTML.
- Btw: There are many !important styles. Why is that?

- The align attribute for the img element is deprecated in HTML5
- Empty elements have bad semantics: . I know, it's a 
  neat CSS trick, but that doesn't make it better. A background image would 
  be a better choice here.
-  is similar. Just 
  put the font character inside the link and set the font properly. However, 
  not everybody executes remote font files (I usually don't by default). 
  These people see strange letters instead of carousel arrows.

  There are a few tricks involving putting real arrow characters inside 
  another container and adding font defining classes / display: none for the 
  arrow after a modernizr-like detection for font-face support.
  Or just use SVG images as link content.

I did not dig deeper so far, as said, that was a quick view.

-1 at the implementation, sorry.

nd
-- 
Das einzige, das einen Gebäudekollaps (oder auch einen
thermonuklearen Krieg) unbeschadet übersteht, sind Kakerlaken
und AOL-CDs.
  -- Bastian Lipp in dcsm

Re: Logging multiple values for the same cookie name?

[André Malo]

* William A. Rowe Jr. wrote:

> In working through this code, I realized that you may have multiple
> cookie headers of multiple values for the same cookie name.
>
> Mark Thomas looked at the spec for me and determined they would be
> entirely permissible by RFC 6265 S4.2.2.  But today we simply log one and
> done.
>
> I don't want to hold up 2.4 or 2.2 for such an issue, but would like to
> correct it in the near-term.  The discussion question is; how to indicate
> a value list rather than a value in our logging?

I'd suggest separating the values with semicolons.

nd
-- 
"Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III"

Im Westen was neues: 

Re: Duplicate directive HeartbeatStorage

[André Malo]

On Thursday 20 February 2014 16:13:01 Eric Covener wrote:
> On Thu, Feb 20, 2014 at 10:04 AM, André Malo  wrote:
> > Anyone?
> >
> > The doc build tools are confused as well ;-)
> >
> > nd
> >
> > On Sunday 16 February 2014 15:58:18 André Malo wrote:
> >> Hi there,
> >>
> >> We do have one duplicate directive in our tree: HeartbeatStorage
> >> (defined in mod_lbmethod_heartbeat.c and mod_heartmonitor.c)
> >>
> >> I find this confusing. How does it work? Without digging through the
> >> config code: are they even both initialized? What if they were defined
> >> with different syntax specs? Or is it just a mistake?
>
> I do recall it is viable for two modules to use the same directive and
> both get called back when it's specified.  They could have differeng
> TAKE12, RAW_ARGS, etc as long as the actual args were compatible with
> both.


Hmm. Then it's still the question, why would we want that? It looks to me like 
a design error (besides, as said, it's confusing).

I'm not sure, when I'll get around to dig through the code. So, if someone can 
help here, it would be appreciated :-)

nd

Re: Duplicate directive HeartbeatStorage

[André Malo]

Anyone?

The doc build tools are confused as well ;-)

nd

On Sunday 16 February 2014 15:58:18 André Malo wrote:
> Hi there,
>
> We do have one duplicate directive in our tree: HeartbeatStorage (defined
> in mod_lbmethod_heartbeat.c and mod_heartmonitor.c)
>
> I find this confusing. How does it work? Without digging through the config
> code: are they even both initialized? What if they were defined with
> different syntax specs? Or is it just a mistake?
>
> Thanks, nd

Duplicate directive HeartbeatStorage

[André Malo]

Hi there,

We do have one duplicate directive in our tree: HeartbeatStorage (defined in 
mod_lbmethod_heartbeat.c and mod_heartmonitor.c)

I find this confusing. How does it work? Without digging through the config 
code: are they even both initialized? What if they were defined with 
different syntax specs? Or is it just a mistake?

Thanks, nd
-- 
s;.*;aoaaaoaaoaaaom:a:alataa:aaoat:a:a:a
maoaa:a:laoata:a:oia:a:o:a:m:a:o:alaoooat:aaool:aaoaa
matooololaaatoto:aaa:o:a:o:m;;s:\s:\::g;y;mailto:;
\40\51/\134\137|ndparker ;;print;

Re: svn commit: r1557641 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h modules/mappers/mod_dir.c modules/mappers/mod_rewrite.c modules/mappers/mod_rewrite.h

[André Malo]

* cove...@apache.org wrote:

> Author: covener
> Date: Mon Jan 13 01:51:58 2014
> New Revision: 1557641
>
> URL: http://svn.apache.org/r1557641
> Log:
> don't search for directory indexes/directoryslashes if a URL is in the
> middle of being rewritten [in per-dir context]. PR53929
>
>
> Modified: httpd/httpd/trunk/modules/mappers/mod_rewrite.h
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mappers/mod_rewrit
>e.h?rev=1557641&r1=1557640&r2=1557641&view=diff
> =
>= --- httpd/httpd/trunk/modules/mappers/mod_rewrite.h (original)
> +++ httpd/httpd/trunk/modules/mappers/mod_rewrite.h Mon Jan 13 01:51:58
> 2014 @@ -29,6 +29,8 @@
>  #include "apr_optional.h"
>  #include "httpd.h"
>
> +#define REDIRECT_HANDLER_NAME "redirect-handler"
> +
>  /* rewrite map function prototype */
>  typedef char *(rewrite_mapfunc_t)(request_rec *r, char *key);

Should it be prefixed (e.g. with REWRITE_)?

And maybe the handler name, too? (this one trunk only).

nd
-- 
Wer sein Wissen nicht teilen will, besitzt wahrscheinlich zu wenig davon.
  -- Unbekannt

Re: svn commit: r1533810 - in /httpd/httpd/trunk: docs/man/rotatelogs.8 docs/manual/programs/rotatelogs.html.en support/rotatelogs.c

[André Malo]

* Ben Reser wrote:

> On 10/20/13 5:37 AM, André Malo wrote:
> > * bre...@apache.org wrote:
> >> Author: breser
> >> Date: Sat Oct 19 19:10:33 2013
> >> New Revision: 1533810
> >>
> >> * docs/man/rotatelogs.8,
> >>   docs/manual/programs/rotatelogs.html.en: Update for -d option.
> >
> > Huh. These files are both generated (or should be). Please update
> > rotatelogs.xml instead.
>
> Oops thanks fixed in r1533935.
>
> Why are the generated files committed though?

For one thing, oversight. The docs are shipped in generated form, and 
failures can be seen early (the docs build process happens to fail from 
time to time, because of weird java reasons (typically stack sizes and 
character encodings - depending on OS and java installation)).

The other thing is, that the docs are simply checked out for the online 
manual.

nd
-- 
"Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III"

Im Westen was neues: <http://pub.perlig.de/books.html#apache2>

Re: svn commit: r1533810 - in /httpd/httpd/trunk: docs/man/rotatelogs.8 docs/manual/programs/rotatelogs.html.en support/rotatelogs.c

[André Malo]

* bre...@apache.org wrote:

> Author: breser
> Date: Sat Oct 19 19:10:33 2013
> New Revision: 1533810

> * docs/man/rotatelogs.8,
>   docs/manual/programs/rotatelogs.html.en: Update for -d option.

Huh. These files are both generated (or should be). Please update 
rotatelogs.xml instead.

nd
-- 
"Die Untergeschosse der Sempergalerie bleiben währenddessen aus
 statistischen Gründen geflutet." -- Spiegel Online

Re: [DISCUSS] Dropping the E-word from mod_lua (SFW)

[André Malo]

* Jeff Trawick wrote:

> On Fri, Aug 2, 2013 at 8:41 AM, Daniel Gruno  wrote:
> >
> > I'd like to change the note to something along these lines:
> > 
> > mod_lua is in a state of continuous development. Usage
> > and behavior is subject to change at any time, even between stable
> > releases of the 2.4.x series. Be sure to check the CHANGES file before
> > upgrading
> > 
>
> That text sounds fine but I don't see that as being reassuringly
> non-"Experimental" from the point of an enterprise distributor or a site
> administrator.  Given that declaration, it would be naive to make your
> production site dependent on a fair amount of interesting code for
> mod_lua unless you think you can drop everything to tweak your scripts in
> order to pick up a httpd security fix at some arbitrary future time, or
> you can watch mod_lua development steadily to be prepared ahead of time. 
> "Status: Experimental" is the flag we have to say "watch out for this
> module", which seems appropriate still.

+1.

If you want to break things AND be not experimental, do the changes simply 
in trunk only (we've had that discussion...). Also, if I remember 
correctly, there's a CTR policy for mod_lua/2.4.x in place, which needs to 
be revoked once the module goes into a stable mode.

nd
-- 
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;

#  André Malo  #  http://pub.perlig.de  #

Re: Decrypting mod_session-created cookie

[André Malo]

On Tuesday 09 July 2013 14:51:49 Mikhail T. wrote:
> 09.07.2013 08:31, Eric Covener написав(ла):
> > I am not surprised that separately documenting is not a priority for
> > anyone,  given it's implemented in httpd for anyone to see.
>
> Source code is not documentation, is it? In matters of encryption
> especially the methods chosen should be documented better -- not only
> for interoperability, but also to allow to better judge the strengths of
> the method (not that I personally am capable of the latter).

I agree. And everybody is welcome to help fixing that issue.

nd

Re: svn commit: r1493247 - /httpd/httpd/branches/2.4.x/STATUS

[André Malo]

* Stefan Fritsch wrote:

> Hi André,
>
> I consider this a new vote and therefore have removed your -1. If you
> still are -1, please add it to STATUS again.
>
> On Friday 14 June 2013, s...@apache.org wrote:
> > Author: sf
> > Date: Fri Jun 14 21:07:19 2013
> > New Revision: 1493247
> >
> > URL: http://svn.apache.org/r1493247
> > Log:
> > update strtoul proposal to include a minor MMN bump. Keep jim's
> > conditional vote
> >
> > Modified:
> > httpd/httpd/branches/2.4.x/STATUS

No further objections. I'm +-0 now (but I won't enter that into STATUS).

nd

Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS

[André Malo]

On Friday 14 June 2013 17:34:26 Rainer Jung wrote:
> On 14.06.2013 16:41, André Malo wrote:
> > On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote:
> >> On Tuesday 11 June 2013, André Malo wrote:
> >>>>trunk patch: http://svn.apache.org/r1491155
> >>>>2.4.x patch: trunk patch works
> >>>>nd: why would you do that in a stable branch?
> >>>>
> >>>> +  sf: Because it is only annoying and serves no purpose
> >>>> anymore. If you +  want, we can make it a minor MMN bump
> >>>> for adding a "new" API. +1: sf, covener
> >>>>
> >>>>-1: nd
> >>>
> >>> Long discussions in STATUS are kinda tedious ;-)
> >>>
> >>> Well, I think, such changes are what trunk is for. Why not simply
> >>> leave  everything below as-is? Even more if it removes only an
> >>> annoyance? Or is there a real technical reason I'm just not seeing
> >>> right now?
> >
> > [...]
> >
> >> Or, is there a real technical reason to keep it broken in 2.4?
> >
> > Annoying rhetoric games aside - we went from "only annoying" to "broken".
> > What is it now?
> >
> > No other opinion on this?
>
> As far as I understand the matter, the block removed by the above commit
> would throw a compiler error if code uses strtoul() and includes httpd.h.
>
> The motivation was that at the time the block was introduced some
> supported platforms, e.g. SunOS 4, did not have strtoul(), so it was
> helpful to throw that error even when compiled on other platforms to
> ensure compatibility.
>
> The error will also be thrown for any 3rd-party code that uses strtoul()
> and includes httpd.h when being compiled - so practically all modules
> are prohibited to use strtoul().
>
> The function is part of C89 which we assume as a minimum when compiling
> Apache 2.4. So I do not see any positive effects of the old block. I do
> recognize, that it breaks module compilation for modules using
> strtoul(). So the proposed change removes an obstacle for full CC89
> support in modules. Furthermore I can not imagine any risk of breaking
> stuff that worked before removing the block.
>
> Based on that I am +1 to remove the block.

I agree, that the block should simply die. However, I question the value of 
doing cosmetical changes in our stable branches (which is the justification 
in STATUS).

So the question in this specific case is: is it a cosmetical change or not?

nd

Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS

[André Malo]

On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote:
> On Tuesday 11 June 2013, André Malo wrote:
> > >trunk patch: http://svn.apache.org/r1491155
> > >2.4.x patch: trunk patch works
> > >nd: why would you do that in a stable branch?
> > >
> > > +  sf: Because it is only annoying and serves no purpose
> > > anymore. If you +  want, we can make it a minor MMN bump
> > > for adding a "new" API. +1: sf, covener
> > >
> > >-1: nd
> >
> > Long discussions in STATUS are kinda tedious ;-)
> >
> > Well, I think, such changes are what trunk is for. Why not simply
> > leave  everything below as-is? Even more if it removes only an
> > annoyance? Or is there a real technical reason I'm just not seeing
> > right now?

[...]
>
> Or, is there a real technical reason to keep it broken in 2.4?

Annoying rhetoric games aside - we went from "only annoying" to "broken". What 
is it now?

No other opinion on this?

nd

Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS

[André Malo]

* s...@apache.org wrote:

> Author: sf
> Date: Mon Jun 10 21:41:07 2013
> New Revision: 1491612
>
> URL: http://svn.apache.org/r1491612
> Log:
> comment
>
> 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=149161
>2&r1=1491611&r2=1491612&view=diff
> =
>= --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Mon Jun 10 21:41:07 2013
> @@ -198,6 +198,8 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>trunk patch: http://svn.apache.org/r1491155
>2.4.x patch: trunk patch works
>nd: why would you do that in a stable branch?
> +  sf: Because it is only annoying and serves no purpose anymore. If
> you +  want, we can make it a minor MMN bump for adding a "new"
> API. +1: sf, covener
>-1: nd

Long discussions in STATUS are kinda tedious ;-)

Well, I think, such changes are what trunk is for. Why not simply leave 
everything below as-is? Even more if it removes only an annoyance? Or is 
there a real technical reason I'm just not seeing right now?

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

Re: svn commit: r1461869 - /httpd/httpd/trunk/server/util.c

[André Malo]

* Rainer Jung wrote:

> On 17.04.2013 11:38, Plüm, Rüdiger, Vodafone Group wrote:
> >> -Original Message-
> >> From: André Malo [mailto:n...@perlig.de]
> >> Sent: Mittwoch, 17. April 2013 11:04
> >> To: dev@httpd.apache.org
> >> Subject: Re: svn commit: r1461869 - /httpd/httpd/trunk/server/util.c
> >>
> >> * Rainer Jung wrote:
> >>
> >>
> >> http://people.apache.org/~rjung/patches/ap_escape_logitem_enhanced.pat
> >>ch
> >>
> >> +ret = apr_palloc(p, length + 3 * escapes);
> >>
> >> It should be still 4 * escapes ('\xHH').
> >
> > I don't think so. If you have the binary data of \xHH it is ok to have
> > one byte for the original data plus 3 bytes for the escapes and that is
> > length + 3 * escapes. The storage for the original data is in length.
> > But I admit that I got confused by that as well :-)

O. right.

>
> So probably we should use a better comment as the one in the patch
> currently:
>
> /* 3 * escapes for the overhead in '\\' + c2x() */
>
> ;)

good idea ;)

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

<http://pub.perlig.de/books.html#apache2>

Re: svn commit: r1461869 - /httpd/httpd/trunk/server/util.c

[André Malo]

* André Malo wrote:

> * Rainer Jung wrote:
> > A quick draft patch is at
> >
> > http://people.apache.org/~rjung/patches/ap_escape_logitem_enhanced.patc
> >h
>
> +ret = apr_palloc(p, length + 3 * escapes);
>
> It should be still 4 * escapes ('\xHH').

Also, escapes should be apr_size_t as well, I think.

nd
-- 
s  s^saoaaaoaaoaaaom  a  alataa  aaoat  a  a
a maoaa a laoata  a  oia a o  a m a  o  alaoooat aaool aaoaa
matooololaaatoto  aaa o a  o ms;s;\s;s;g;y;s;:;s;y#mailto: #
 \51/\134\137| http://www.perlig.de #;print;# > n...@perlig.de

Re: svn commit: r1461869 - /httpd/httpd/trunk/server/util.c

[André Malo]

* Rainer Jung wrote:

> On 27.03.2013 22:57, jaillet...@apache.org wrote:
> > Author: jailletc36
> > Date: Wed Mar 27 21:57:44 2013
> > New Revision: 1461869
> >
> > URL: http://svn.apache.org/r1461869
> > Log:
> > Be more clever when allocating memory for log item to be escaped.
> > This should save about 70-100 bytes in the request pool with the
> > default config.
> >
> > Modified:
> > httpd/httpd/trunk/server/util.c
> >
> > Modified: httpd/httpd/trunk/server/util.c
> > URL:
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util.c?rev=146186
> >9&r1=1461868&r2=1461869&view=diff
> > ===
> >=== --- httpd/httpd/trunk/server/util.c (original)
> > +++ httpd/httpd/trunk/server/util.c Wed Mar 27 21:57:44 2013
> > @@ -1850,12 +1850,26 @@ AP_DECLARE(char *) ap_escape_logitem(apr
> >  char *ret;
> >  unsigned char *d;
> >  const unsigned char *s;
> > +int length = 0;
> >
> >  if (!str) {
> >  return NULL;
> >  }
> >
> > -ret = apr_palloc(p, 4 * strlen(str) + 1); /* Be safe */
> > +/* First, compute the space needed for the escaped string.
> > + * This could be tweaked a bit for '\b', '\n'... These characters
> > + * should not be common, so do not bother. */
> > +s = (const unsigned char *)str;
> > +for (; *s; ++s) {
> > +if (TEST_CHAR(*s, T_ESCAPE_LOGITEM)) {
> > +length += 4;/* for '\\' + c2x() */
> > +}
> > +else {
> > +length++;
> > +}
> > +}
> > +
> > +ret = apr_palloc(p, length + 1);
> >  d = (unsigned char *)ret;
>
> Here we treat CPU against memory. AFAIK this function is in the hot code
> path, because it is used for many of the fields used in the default
> access log format and also in many custom ones. All other uses seem to
> be either trace log messages, some (few) error log messages and
> mod_status output. For those cases I think neither the CPU nor the
> Memory differences are important.
>
> In the access log case it seems the typical fields which are run through
> ap_escape_logitem() should rarely contain characters to escape. So an
> alternative strategy would be to simply copy the string if we don't find
> a character to escape. The second check for each char is not necessary
> then.
>
> A quick draft patch is at
>
> http://people.apache.org/~rjung/patches/ap_escape_logitem_enhanced.patch

+ret = apr_palloc(p, length + 3 * escapes);

It should be still 4 * escapes ('\xHH').

nd
-- 
Das, was ich nicht kenne, spielt stückzahlmäßig *keine* Rolle.

   -- Helmut Schellong in dclc

Re: [Result] [Vote] Overhaul modules.apache.org (second try)

[André Malo]

Damn.

+1 from me ;)

nd

On Thursday 31 January 2013 14:57:09 Daniel Gruno wrote:
> With another 72 hours passed and no new votes cast, I am satisfied that
> the motion has been carried, so to speak. I'll get started preparing the
> new site and contacting old authors/maintainers.
>
> With regards,
> Daniel.
>
>
> Previous vote email follows, for reference:
> ---
> With the clock passing 13:20 GMT, the voting has ended, and been
> tallied. There was some concern about the DNS solution in the proposal,
> which has been adjusted to a subdirectory instead (and all URLs on the
> old site has been adjusted to use relative hrefs), and with no
> objections to that, the votes are as follows:
>
> +1: 15(13) - humbedooh, trawick, rpluem, jim, niq, fuankg, gsmith,
>  rbowen, minfrin, rjung, sfritsch, covener, fielding,
>  gmcdonald (ex officio, non-binding in this case),
>  matsumoto (non-binding)
>  0:  none
> -1:  none
>
> And thus, I am pleased to say the vote passes. I will begin prepping bil
> (the machine on which all of this runs) for the new site and piggyback
> the old site onto the new one. I will also send out an email to module
> maintainers, informing them of the new site, once it's up and running
> well. I will also start a thread on modules-...@httpd.apache.org to get
> some suggestions and reviews coming in at a steady pace.
>
> Thanks for your votes and support, and I hope to see you enjoying the
> new site!
>
>
> With regards,
> Daniel, on behalf of the team behind the new site.
>
> PS: We are now 4 people working on the site, but if anyone else would
> like to volunteer, we can always use an extra helping hand.
>
>
> 
> Proposal (for record keeping's sake)
> 
> 1) Move the current modules.apache.org to modules.apache.org/archive
> 2) Create a link on both modules.apache.org and
> modules.apache.org/archive linking to each other.
> 3) Replace modules.apache.org with the new modules site, currently
> available at http://modules.humbedooh.com and also available in svn for
> review.
> 4) Start afresh with a new, empty database on modules.apache.org and
> have modules-archive.apache.org retain the old database.
> 5) Contact all authors who have created or modified a module on the site
> within the last 2 years (this is 59 authors), and inform them of the new
> site, encouraging them to resubmit their modules.
> 6) Allow modules.apache.org to fetch DOAP files for projects, placed
> anywhere on the Internet, thus acting as an aggregator of publicly
> available information.

Re: [Result] [Vote] Overhaul modules.apache.org

[André Malo]

Oh, a vote deep in the middle of a discussion thread :-(

nd

On Monday 28 January 2013 14:25:09 Daniel Gruno wrote:
> With the clock passing 13:20 GMT, the voting has ended, and been
> tallied. There was some concern about the DNS solution in the proposal,
> which has been adjusted to a subdirectory instead (and all URLs on the
> old site has been adjusted to use relative hrefs), and with no
> objections to that, the votes are as follows:
>
> +1: 15(13) - humbedooh, trawick, rpluem, jim, niq, fuankg, gsmith,
>  rbowen, minfrin, rjung, sfritsch, covener, fielding,
>  gmcdonald (ex officio, non-binding in this case),
>  matsumoto (non-binding)
>  0:  none
> -1:  none
>
> And thus, I am pleased to say the vote passes. I will begin prepping bil
> (the machine on which all of this runs) for the new site and piggyback
> the old site onto the new one. I will also send out an email to module
> maintainers, informing them of the new site, once it's up and running
> well. I will also start a thread on modules-...@httpd.apache.org to get
> some suggestions and reviews coming in at a steady pace.
>
> Thanks for your votes and support, and I hope to see you enjoying the
> new site!
>
>
> With regards,
> Daniel, on behalf of the team behind the new site.
>
> PS: We are now 4 people working on the site, but if anyone else would
> like to volunteer, we can always use an extra helping hand.
>
>
> 
> Proposal (for record keeping's sake)
> 
> 1) Move the current modules.apache.org to modules.apache.org/archive
> 2) Create a link on both modules.apache.org and
> modules.apache.org/archive linking to each other.
> 3) Replace modules.apache.org with the new modules site, currently
> available at http://modules.humbedooh.com and also available in svn for
> review.
> 4) Start afresh with a new, empty database on modules.apache.org and
> have modules-archive.apache.org retain the old database.
> 5) Contact all authors who have created or modified a module on the site
> within the last 2 years (this is 59 authors), and inform them of the new
> site, encouraging them to resubmit their modules.
> 6) Allow modules.apache.org to fetch DOAP files for projects, placed
> anywhere on the Internet, thus acting as an aggregator of publicly
> available information.

Re: [VOTE] accept mod_macro as standard module in httpd

[André Malo]

* Eric Covener wrote:

> I was preparing the IP clearance forms and noticed our original "vote"
> thread was more of a discussion. I wanted to record a formal vote here
> so I can link to it.
>
> Pending IP clearance...
>
> [+1] accept mod_macro as a standard module and responsibility for its
> maintenance
> [ +/- 0] don't care won't help
> [ -1] don't accept mod_macro as a standard module

+1.
-- 
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~  # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord(  # André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see;  #  http://pub.perlig.de/ ;

Re: Volunteers to drive an MSI build

[André Malo]

* Gregg Smith wrote:

> On 11/28/2012 8:10 AM, André Malo wrote:
> > Some individuals have provided those builds. Nobody has voted on them
> > (because, how could one - I know, I wouldn't). They are not official
> > relases.
>
> Which to the average user that does not know this policy, can easily be
> construed as Official. I have not read every word here but I see nothing
> jumping out at me stating they are to not to considered official.
> http://www.apache.org/dist/httpd/binaries/win32/

Yes :/ (same for netware builds, FWIW)

nd
-- 
"Die Untergeschosse der Sempergalerie bleiben währenddessen aus
 statistischen Gründen geflutet." -- Spiegel Online

Re: Volunteers to drive an MSI build

[André Malo]

On Wednesday 28 November 2012 17:02:30 Yehuda Katz wrote:
> On Wed, Nov 28, 2012 at 10:35 AM, André Malo  wrote:
> > > You know that, and I know that. Jst as our Windows users know
> > > they have no use for source code.
> >
> > The discussion is moot. The ASF will not provide binary software.
>
> Is that a new policy? ASF has provided (i.e. made available on
> httpd.apache.org distribution mirrors) Windows binaries of HTTPD for (I can
> say every release, since I did not check, but you get the idea).
> The last one released was on 30-Jan-2012 of
> httpd-2.2.22-win32-x86-openssl-0.9.8t.msi (see
> http://www.us.apache.org/dist//httpd/binaries/win32/).
> There are *still* NetWare binaries being built.

No, the ASF has not. And the policy (nor this discussion) is not new.

Some individuals have provided those builds. Nobody has voted on them 
(because, how could one - I know, I wouldn't). They are not official relases.

And that's where the circle closes. The ASF does not and can not provide 
binary builds. Volunteering individuals may do that.

nd

Re: Volunteers to drive an MSI build

[André Malo]

On Wednesday 28 November 2012 15:01:15 Igor Galić wrote:
> - Original Message -
>
> > > -Original Message-
> > > From: Jim Jagielski [mailto:j...@jagunet.com]
> > > Sent: Mittwoch, 28. November 2012 13:22
> > > To: dev@httpd.apache.org
> > > Subject: Re: Volunteers to drive an MSI build
> > >
> > >
> > > On Nov 28, 2012, at 4:26 AM, Igor Galić 
> > >
> > > wrote:
> > > > * we (the ASF) should provide an official Windows Build
> > >
> > > Why?
> >
> > Exactly. Binaries are just convenience. I support people here that
> > want to create
> > whatever Windows binary (zip, exe, msi) as a convenience to our
> > users, but the official
> > distributions are IMHO always source distributions.
>
> You know that, and I know that. Jst as our Windows users know
> they have no use for source code.

The discussion is moot. The ASF will not provide binary software.

nd

Re: svn commit: r1406719 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number include/http_core.h server/core.c server/protocol.c

[André Malo]

On Wednesday 07 November 2012 22:16:46 Graham Leggett wrote:
> On 07 Nov 2012, at 10:35 PM, André Malo  wrote:
> >> It feels wrong targeting 0.9 only, would it be possible to do this in a
> >> generic way, say by listing the ones accepted, or by specifying a
> >> minimum?
> >
> > Hmm, what would be the use case? I see it with HTTP/0.9, but I don't see
> > it with >= HTTP/1.0. I'd prefer kind of "duck typing" for those, like
> > asking "is a valid host header present?" - which is already possible.
>
> I've had problems in the past with HTTP/1.0 requests to restful services
> causing keepalive problems with load balancers, and I'd like to be able to
> ban HTTP/1.0 requests, allowing HTTP/1.1 only.

Huh. It sounds more like fixing the loadbalancers would be the way to go. Most 
non-browser clients don't speak HTTP/1.1 anyway.

nd

Re: svn commit: r1406719 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number include/http_core.h server/core.c server/protocol.c

[André Malo]

* Graham Leggett wrote:

> On 7 Nov 2012, at 17:56, s...@apache.org wrote:
> > Author: sf
> > Date: Wed Nov  7 16:56:38 2012
> > New Revision: 1406719
> >
> > URL: http://svn.apache.org/viewvc?rev=1406719&view=rev
> > Log:
> > New directive HttpProtocol which allows to disable HTTP/0.9 support.
>
> It feels wrong targeting 0.9 only, would it be possible to do this in a
> generic way, say by listing the ones accepted, or by specifying a
> minimum?

Hmm, what would be the use case? I see it with HTTP/0.9, but I don't see it 
with >= HTTP/1.0. I'd prefer kind of "duck typing" for those, like 
asking "is a valid host header present?" - which is already possible.

nd
-- 
"Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3)"
  -- aus einer Rezension

Re: svn commit: r1032431 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_rewrite.c

[André Malo]

* Eric Covener wrote:

> On Thu, Oct 4, 2012 at 2:05 PM, Graham Leggett  wrote:
> > On 4 Oct 2012, at 17:32, Eric Covener  wrote:
> >>> URL: http://svn.apache.org/viewvc?rev=1032431&view=rev
> >>> Log:
> >>> mod_rewrite: Fix the RewriteEngine directive to work within a
> >>> location. Previously, once RewriteEngine was switched on globally,
> >>> it was impossible to switch off.
> >>>
> >>> +a->baseurl = (overrides->baseurl_set == 0) ? base->baseurl :
> >>> overrides->baseurl; +a->baseurl_set = overrides->baseurl_set ||
> >>> base->baseurl_set;
> >>
> >> PR https://issues.apache.org/bugzilla/show_bug.cgi?id=53963 points out
> >> that mergeing the base is probably not very useful and actually harms
> >> configs where no rewritebase is required in some subdirs but present
> >> in parent dirs.
> >>
> >> Any issue with dropping this part of the change?
> >
> > Having an arbitrary inconsistent behaviour from a directive in a module
> > already noted for its complexity is a really bad thing. What we should
> > support instead is the ability to turn RewriteBase off if needed, with
> > something like "RewriteBase off".
>
> "Rewritebase off" to undo the copy of base URL from the parent to the
> subdir seems wrong.  I'll try to merge in a value less likely to be
> wrong.

Hmm. The very sole concept of RewriteBase is "base for this location and 
this location only". So merging is most certainly a nogo. It *will* break 
stuff. mod_rewrite already has enough bad guessings built in ;)

nd
-- 
Da fällt mir ein, wieso gibt es eigentlich in Unicode kein
"i" mit einem Herzchen als Tüpfelchen? Das wär sooo süüss!

 -- Björn Höhrmann in darw

Re: md5crypt passwords

[André Malo]

* Reindl Harald wrote:

> i only needed to point out that weakhash(weakhash(weakhash()))
> does not result in stronghash() no matter how often you wrap

I'm not sure, why the topic drifted there anyway. md5crypt does not actually 
nest hashes like this.

nd
-- 
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;

#  André Malo  #  http://www.perlig.de  #

Re: svn commit: r1341930 - /httpd/httpd/trunk/docs/manual/suexec.html.en

[André Malo]

On Thursday 24 May 2012 00:34:20 Joe Schaefer wrote:
> This won't happen once the docs are migrated to the CMS ;-)

I didn't happen the last 10 years or so ;)

nd

Re: svn commit: r1341930 - /httpd/httpd/trunk/docs/manual/suexec.html.en

[André Malo]

* jor...@apache.org wrote:

> Author: jorton
> Date: Wed May 23 16:06:02 2012
> New Revision: 1341930
>
> URL: http://svn.apache.org/viewvc?rev=1341930&view=rev
> Log:
> * docs/manual/suexec.html.en: Update for syslog logging.

Duh. Am I missing something here or didn't you update the XML file?

nd
-- 
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~  # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord(  # André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see;  #  http://www.perlig.de/ ;

Re: IfModule doesn't work in certain case

[André Malo]

Also this belongs to the user list...

nd

On Thursday 12 April 2012 10:44:04 Igor Galić wrote:
> - Original Message -
>
> > I wonder if you would consider this a bug. Here is the situation.
> >
> > I had a config file in conf.d which loaded some modules.
> > Alphabetically, it came after the loading of the vhost files. The
> > IfModule blocks would not work. In this same order, if I don't use
>
> "would not work" << what, exactly, does that mean?
> Didn't parse/execute/was ignored?
> What did it look like?
> What, exactly, did the error log say?
>
> > IfModule, the directives still work fine. I don't know if this is
> > expected behavior, but I would think either the IfModule should work
> > or if the reason the IfModule doesn't work is because the modules
> > weren't loaded yet, I should get an error and the directives
> > shouldn't work when I don't use the IfModule. Makes sense?
>
> only with more context;)
>
> > -William Leonard
>
> i

Re: Proposal: adoption of mod_policy subproject

[André Malo]

On Wednesday 29 February 2012 04:11:35 William A. Rowe Jr. wrote:
>
> I withdraw this vote, reverting my position to -1, until collaboration and
> respect for options and insights of fellow committers as well as project
> decisions and votes can be consistently demonstrated.

I always thought, you'd have to provide technical reasons for -1 votes (?).

nd

Re: [proposed] remove docs/1.3/

[André Malo]

* William A. Rowe Jr. wrote:

> On 2/26/2012 2:11 PM, André Malo wrote:
> > * William A. Rowe Jr. wrote:
> >> Doesn't it seem overtime to take down 1.3 docs from the site,
> >> altogether?
> >
> > Why?
>
> Because 1.3 code and docs are no longer maintained.  Because 1.3 docs
> shipped in the tarball, they got the whole deal when they downloaded it.
>
> By continuing to publish something out-of-date, we imply to users that
> there is some support of that software that does not in fact exist IMHO.
> Serving out-of-date docs is a disservice to our users.  I agree that
> anyone hitting a 1.3/ URL should be redirected to a pointer that they
> need to re-obtain the tarball and use the embedded docs shipped with
> httpd 1.3.42.

I don't think so. A *lot* of links out there still point to these docs (and 
that won't change). If not for anything else, the 1.3 docs publication can 
still be used to point out history and differences and support 
argumentation. It's hard to reference a tarball (which most people didn't 
even download).

Furthermore: most people I know, who are still using 1.3, don't use it, 
because they want to, they use it, because they have no other choice for 
some reason or another.

A compromise I'd actively support would be:

- to not only put these red blocks above each document, but 
  provide 'position: fixed' block, being always visible (for modern 
  browsers) (maybe on the left side, simply saying "UNSUPPORTED SOFTWARE" or 
  something, linking the read block above.)

- put robots=noindex into the documents and/or add a line to the robots.txt

- we could probably remove 1.3 docs from the navigation

nd
-- 
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;

#  André Malo  #  http://www.perlig.de  #

Re: [proposed] remove docs/1.3/

[André Malo]

Folks, please keep this discussion on docs@, too.

* Rich Bowen wrote:

> On Feb 26, 2012, at 7:30 AM, Tim Bannister wrote:
> > On 26 Feb 2012, at 10:34, Graham Leggett wrote:
> >> On 26 Feb 2012, at 9:35 AM, William A. Rowe Jr. wrote:
> >>> Ok folks, it's been a "few years"... over 10, in fact, that 1.3 has
> >>> been dead.
> >>>
> >>> Doesn't it seem overtime to take down 1.3 docs from the site,
> >>> altogether?
> >>
> >> I find that from time to time, v1.3 documentation comes up in Google
> >> searches, which probably confuses users who don't know what they're
> >> looking at.
> >
> > There are ways to leave it there but persuade crawlers not to index it.
> > Maybe even serve it with 410 status and some JavaScript to point out
> > that the page is deprecated.
> >
> > I think the first one is worthwhile and the second one is not worth the
> > extra effort.
>
> We're already using the
>
> http://httpd.apache.org/docs/current/"/>
>
> to tell Google not to index the pages, although that's not (yet) on all
> of the 1.3 doc pages - Unfortunately that's something of a manual process
> due to the fact that the 1.3 docs are in HTML, not generated, and that
> not every page in the 1.3 docs has an exact corollary in the /current/
> docs.
>
> There's certainly more we can do to purge it from search engines without
> making it completely unavailable.
>
> I'm somewhat torn on whether we want it to go away entirely - I tend to
> think that what Nick suggests - removing it but making it available as a
> tarball - satisfies those folks who are still running 1.3 for some reason
> that they consider legitimate.
>
> So, +1 to removing the /docs/1.3/ directory, and also to tarring it up
> and making it downloadable from a errordocument that loads for /docs/1.3/
> requests. A .htaccess file with the content negotiation stuff would also
> be a friendly thing to include in that, as Nick suggests.
>
> Prior to doing that, there are some changes that we need to make the
> pointers in them to the current docs actually go the right place. Some of
> the pages reference 2.2 as the current version, and also /current/ still
> points to 2.2. So, give us a moment to resolve those two issues …
>
> --
> Rich Bowen
> rbo...@rcbowen.com :: @rbowen
> rbo...@apache.org



-- 
print "Just Another Perl Hacker";

# André Malo, <http://pub.perlig.de/> #

Re: [proposed] remove docs/1.3/

[André Malo]

* William A. Rowe Jr. wrote:

> On 2/25/2012 10:09 AM, minf...@apache.org wrote:
> > Author: minfrin
> > Date: Sat Feb 25 16:09:03 2012
> > New Revision: 1293634
> >
> > URL: http://svn.apache.org/viewvc?rev=1293634&view=rev
> > Log:
> > The current version of the server is v2.4.
> >
> > Modified:
> > httpd/httpd/branches/1.3.x/htdocs/manual/misc/header.html
>
> Ok folks, it's been a "few years"... over 10, in fact, that 1.3 has
> been dead.
>
> Doesn't it seem overtime to take down 1.3 docs from the site, altogether?

Why?

nd
-- 
"Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3)"
  -- aus einer Rezension

Re: svn commit: r1242950 - /httpd/httpd/branches/2.2.x/docs/manual/style/build.properties

[André Malo]

* Rainer Jung wrote:

> Should be move ab, apxs and logrotate back to section 8? I think they
> have been there until version 2.2.21 and moving them to section 1 was a
> bug for 2.2.x, because it was only meant to be done for 2.4.x and trunk.
>
> For 2.0.x you already have put them into section 8.

I've just documented the current state (ls -1 man/) - and leave the moving 
around to someone else. That would have been my next mail ;-)

nd
-- 
If God intended people to be naked, they would be born that way.
  -- Oscar Wilde

Re: svn commit: r1221296 - /httpd/docs-build/trunk/build.xml

[André Malo]

* Graham Leggett wrote:

> On 10 Feb 2012, at 9:55 AM, Rainer Jung wrote:
> > Since the build system is shared between at least 2.2, 2.4 and trunk,
> > this change also moved the man pages from ab, apxs and logrotate from
> > section 8 to section 1 for 2.2.x. Unfortunately this is now a bit
> > inconsistent, because the bins are still installed to sbin for 2.2.x.
> > Also the specs file contained in 2.2.x does no longer work. See BZ
> > 52594.
> >
> > I guess we should keep the bin files and man pages in the same location
> > where they have been until 2.2.21. It seems we need some kind of
> > version dependency in the build.xml (or a branch of the build system)?
>
> I think for the quickest win a branch will do the trick.
>
> Ideally the type of man page should be a property of the man page
> somehow, not baked into the script that generates it, which is shared
> among many branches.

Hold it, I'm just gonna put it into the version specific property file 
(manual/style/build.properties).

nd
-- 
Das, was ich nicht kenne, spielt stückzahlmäßig *keine* Rolle.

   -- Helmut Schellong in dclc

Re: svn commit: r1239679 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_rewrite.c

[André Malo]

Ouch.

Please add a rule flag, that enables this behaviour, if you really need 
that. mod_rewrite already has enough fancy magic. (and rewriting in 
directory context to a resource named "-" is perfectly valid)

nd

* cove...@apache.org wrote:

> Author: covener
> Date: Thu Feb  2 15:43:41 2012
> New Revision: 1239679
>
> URL: http://svn.apache.org/viewvc?rev=1239679&view=rev
> Log:
> treat a rewriterule substitution that expands to "-" as if the rule
> had a literal "-".
>
> Modified:
> httpd/httpd/trunk/CHANGES
> httpd/httpd/trunk/modules/mappers/mod_rewrite.c
>
> Modified: httpd/httpd/trunk/CHANGES
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1239679&r1=123
>9678&r2=1239679&view=diff
> =
>= --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> +++ httpd/httpd/trunk/CHANGES [utf-8] Thu Feb  2 15:43:41 2012
> @@ -1,6 +1,10 @@
>   -*- coding:
> utf-8 -*- Changes with Apache 2.5.0
>
> +  *) mod_rewrite: Treat a RewriteRule substitution that expands to
> + "-" to behave as if a literal "-" was used in the RewriteRule
> + (no substitution). [Eric Covener]
> +
>*) mod_authnz_ldap: Don't try a potentially expensive nested groups
>   search before exhausting all AuthLDAPGroupAttribute checks on the
>   current group. PR52464 [Eric Covener]
>
> Modified: httpd/httpd/trunk/modules/mappers/mod_rewrite.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mappers/mod_rewrit
>e.c?rev=1239679&r1=1239678&r2=1239679&view=diff
> =
>= --- httpd/httpd/trunk/modules/mappers/mod_rewrite.c (original)
> +++ httpd/httpd/trunk/modules/mappers/mod_rewrite.c Thu Feb  2 15:43:41
> 2012 @@ -3909,6 +3909,7 @@ static int apply_rewrite_rule(rewriterul
>  char *newuri = NULL;
>  request_rec *r = ctx->r;
>  int is_proxyreq = 0;
> +int force_no_sub = 0;
>
>  ctx->uri = r->filename;
>
> @@ -4022,6 +4023,11 @@ static int apply_rewrite_rule(rewriterul
>  newuri = do_expand(p->output, ctx, p);
>  rewritelog((r, 2, ctx->perdir, "rewrite '%s' -> '%s'", ctx->uri,
>  newuri));
> +/* Allow a substitution to resolve to "-" and act like a literal
> "-" */ +if (newuri && *newuri == '-' && !newuri[1]) {
> +newuri = NULL;
> +force_no_sub = 1;
> +}
>  }
>
>  /* expand [E=var:val] and [CO=] */
> @@ -4029,7 +4035,7 @@ static int apply_rewrite_rule(rewriterul
>  do_expand_cookie(p->cookie, ctx);
>
>  /* non-substitution rules ('RewriteRule  -') end here. */
> -if (p->flags & RULEFLAG_NOSUB) {
> +if (p->flags & RULEFLAG_NOSUB || force_no_sub) {
>  force_type_handler(p, ctx);
>
>  if (p->flags & RULEFLAG_STATUS) {



-- 
Da fällt mir ein, wieso gibt es eigentlich in Unicode kein
"i" mit einem Herzchen als Tüpfelchen? Das wär sooo süüss!

 -- Björn Höhrmann in darw

Re: Style violations

[André Malo]

* Guenter Knauf wrote:

> Am 08.01.2012 17:20, schrieb Jim Jagielski:
> > How much is "entirely"?
> >
> > Do the>80char lines in ap_listen.h, ap_mmn.h, ap_mpm.h, ap_provider.h,
> > ap_regex.h, ap_regkey.h, ap_slotmem.h, http_core.h, http_protocol,h,
> > etc etc etc etc also constitute a rating of "entirely"?
> >
> > I'd look for more, but my time is better spent fixing things that
> > I find need-to-be-fixed rather than just pointing them out...
> >
> :-)
>
> on the other side: I've asked me already often if we shouldnt increase
> the maxchar/line; I believe that would in many cases greatly increase
> readability ...
> and honestly: who the heck does nowadays work on a 80-line terminal??
> isnt that a relic inherited from stone-time? I would be fine with f.e.
> 110 or 120 chars/line.

Here it's 80 chars (actually I'm use 78 personally) both about putting 
multiple editors side by side and keeping diffs readable by email clients.

Also, but that's for me, it's way more readable if it's not that wide.

nd
-- 
Gib' mal folgendes in die Kommandozeile ein (und einen Moment warten):

net send localhost "Buuuh!"
Na, erschreckt?  -- Markus Becker in mpdsh

Re: svn commit: r1204200 - in /httpd/httpd/branches/2.4.x: docs/manual/mod/mod_include.xml modules/filters/mod_include.c

[André Malo]

* minf...@apache.org wrote:

> Author: minfrin
> Date: Sun Nov 20 17:53:53 2011
> New Revision: 1204200
>
> URL: http://svn.apache.org/viewvc?rev=1204200&view=rev
> Log:
> Backport:
> mod_include: The SSIAccessEnable directive existed to ensure the addition
> of the "-A" syntax would not break existing configurations in v2.2.
> Remove the directive for v2.4, defaulting the behaviour to enabled.

Wouldn't it be better to keep it, with default swapped? That would make the 
upgrade path easier if you're using the new feature already.

I'd drop it for the next version then.

Maybe issueing a deprecation warning would also be helpful.

nd
-- 
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join   #
 [ $japh =~ /{(.)}/] -> [0] => map $_ -> ()  #André Malo #
=> @japh;# http://pub.perlig.de/ #

Re: [Discuss] [VOTE] Formal deprecation of 2.0.x branch

[André Malo]

* William A. Rowe Jr. wrote:

> So isn't it enough to say that "The project will choose to publish
> further releases only for significant security fixes, or will choose
> instead to publish patches for less significant security fixes for
> 12 months from the date of this final release.  From December 2012,
> no further security patches or releases should be expected for the
> 2.0.x release family."?
>
> More useful here to tweak the message than the plan, no?

I wouldn't call that "final", since, well it obviously isn't.

We should send a clear message here, simply saying:

- no more features
- no more bugfixes, except security related ones
- no more anything after, e.g., 31.12.2012

And we should mean it. If that's the plan, fine.

(I find your wording not that clear, but that may be a language issue on my 
side.)

nd
-- 
"Eine Eieruhr", erklärt ihr Hermann, "besteht aus einem Ei. Du nimmst
das Ei und kochst es. Wenn es hart ist, sind fünf Minuten um. Dann weißt
du, daß die Zeit vergangen ist."
 -- Hannes Hüttner in "Das Blaue vom Himmel"

Re: [VOTE] Formal deprecation of 2.0.x branch

[André Malo]

* William A. Rowe Jr. wrote:

> Stealing a plan executed by Colm for 1.3, I'd like to propose that
> we set a two week window following committers' return-from-ApacheCon
> to execute any backports "of general interest" and apply important
> fixes/backports to pregsub allocation and non-absolute uri parsing.
>
> On approval of this plan, I would offer to introduce the EOL notices
> (as we ultimately committed to 1.3), tag and roll 2.0.65 on Nov 26th
> and we would potentially approve and release 2.0 'final' this month.

I'd prefer a "security only from now on" announcement / warning first, and 
keep it that way about another year or so. I don't think the users of 2.0 
are actually prepared for a statement like "support is gone now, effective 
immediately".

We can put a statement into the docs similar to 1.3 (this time automated...)

.02€

However, since this is supposed to be a vote thread: -1 for "final".

nd
-- 
Real programmers confuse Christmas and Halloween because
DEC 25 = OCT 31.  -- Unknown

  (found in ssl_engine_mutex.c)

Re: svn:externals for docs build

[André Malo]

* Plüm, Rüdiger, VF-Group wrote:

> > -Original Message-
> > From: Jim Jagielski
> > Sent: Mittwoch, 29. Juni 2011 17:39
> > To: dev@httpd.apache.org
> > Cc: d...@httpd.apache.org
> > Subject: Re: svn:externals for docs build
> >
> > On Jun 29, 2011, at 11:00 AM, André Malo wrote:
> > > On Wednesday 29 June 2011 16:47:16 Rich Bowen wrote:
> > >> On Jun 29, 2011, at 10:43 AM, Rich Bowen wrote:
> > >>> [rbowen@Rocinante:apache/httpd-trunk]$ du -ksh ./
> > >>>
> > >>>
> > >>> (06-29 10:39) 249M  ./
> > >>
> > >> Oops. 'make distclean' dropped about 40M off of that. But,
> >
> > still, I think
> >
> > >> it's a pretty small addition.
> > >
> > > Hmm.
> > >
> > > I find 98M in a clean checkout. (69M of that belong to the
> >
> > docs already).
> >
> > > Try make extraclean ;-)
> > >
> > > maybe we should move out the docs entirely?
> > >
> > > nd
> >
> > Is it really worth it?
>
> IMHO not. Is it really that kind of an issue for anybody to checkout
> httpd-trunk including docs? Times of modems should be over :-).

As said, I don't have a strong opinion, but since I hear the modem argument 
a lot: people are connecting mobile these days pretty often and out of my 
own experience - it's mostly just GPRS.

nd
-- 
die (eval q-qq:Just Another Perl Hacker
:-)

# André Malo, <http://www.perlig.de/> #

Re: svn:externals for docs build

[André Malo]

On Wednesday 29 June 2011 16:47:16 Rich Bowen wrote:
> On Jun 29, 2011, at 10:43 AM, Rich Bowen wrote:
> > [rbowen@Rocinante:apache/httpd-trunk]$ du -ksh ./
> > 
> > (06-29 10:39) 249M  ./
>
> Oops. 'make distclean' dropped about 40M off of that. But, still, I think
> it's a pretty small addition.

Hmm.

I find 98M in a clean checkout. (69M of that belong to the docs already).

Try make extraclean ;-)

maybe we should move out the docs entirely?

nd

Re: svn:externals for docs build

[André Malo]

On Wednesday 29 June 2011 15:39:32 Igor Galić wrote:
> > Hey guys,
> >
> > I would like to add an svn:externals for
> > docs/manual/build in trunk - any concerns?

There was a lot of discussion about that in the past (about once every year, I 
think). I don't have a strong opinion about either way, just pointing it out.

IIRC the argument against it was that not every developer should need to load 
the tons of jar files. Thatswhy we provide the doc build tools as a separate 
package in the download directory.

nd

Re: "RewriteRule ... /$1" considered harmful

[André Malo]

* Stefan Fritsch wrote:

> My impression is that mapping to different URLs is by far the more
> frequent use case, but I may be wrong. A different idea would be
>
> - Create new directives RewriteToPath, RewriteToURL that don't do
> guessing. - Document clearly the problems that may be caused by the
> guessing behaviour of RewriteRule. Maybe even mark RewriteRule as
> deprecated in 2.4.

Why not flags to RewriteRule? like

RewriteRule ... /$1 [abs]

(or [rel]).

For compat reasons I'd keep the current behaviour without such a flag.

nd
-- 
"Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III"

Im Westen was neues: 

Re: mysql apache md5

[André Malo]

From the peanut gallery:

Oh dear.

The password encryption is called "MD5 based crypt" (as opposed to the DES 
based crypt used in the early days by various systems). "MD5 based crypt" 
is now standard with modern systems. There's nothing Apache-special about 
the algorithm. We just use a different init string here: $apr1$ instead of 
$1$ to avoid hash matches with the system password database 
(like /etc/shadow).

The only way to mistake it with plain MD5 hashing is being sloppy with 
wording.

See also: http://en.wikipedia.org/wiki/Crypt_%28Unix%29

nd
-- 
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook! Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook? Ook. Ook! Ook! Ook? Ook! Ook. Ook? Ook. Ook.
Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook! Ook! Ook!   Ook! Ook.

docs-buildsystem update

[André Malo]

Hi folks,

I've just updated the docs-build-system and added a check for it to the xslt 
styles. So if you get an error when building the docs saying, your build 
system is out-of-date, just do an svn update on the build directory and try 
again.

nd
-- 
"Die Untergeschosse der Sempergalerie bleiben währenddessen aus
 statistischen Gründen geflutet." -- Spiegel Online

Re: svn commit: r1044067 - /httpd/httpd/trunk/docs/manual/vhosts/name-based.xml

[André Malo]

On Thursday 09 December 2010 19:24:17 cove...@apache.org wrote:
> Author: covener
> Date: Thu Dec  9 18:24:17 2010
> New Revision: 1044067
>
> Modified: httpd/httpd/trunk/docs/manual/vhosts/name-based.xml
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/vhosts/name-base
>d.xml?rev=1044067&r1=1044066&r2=1044067&view=diff
> ===
>=== --- httpd/httpd/trunk/docs/manual/vhosts/name-based.xml (original) +++
> httpd/httpd/trunk/docs/manual/vhosts/name-based.xml Thu Dec  9 18:24:17
> 2010 @@ -83,7 +83,7 @@
>  matches the requested hostname. If it finds one, then it uses the
> configuration for that server.
>
> - If no matching ServerName or ServerAlias is
> found in the + If no matching ServerName
> or ServerAlias is found in the set of virtual hosts matching the
> NameVirtualHost directive, then the first listed virtual
> host that matches the IP address will be used.

I think, a tiny nested section would be appropriate here.

nd

Re: svn commit: r1041050 [1/2] - /httpd/httpd/trunk/docs/manual/mod/

[André Malo]

* iga...@apache.org wrote:

> Author: igalic
> Date: Wed Dec  1 15:25:11 2010
> New Revision: 1041050
>
> URL: http://svn.apache.org/viewvc?rev=1041050&view=rev
> Log:
> fixing braino in r1041047, this should now fix pr#50381
>
> Modified:
> httpd/httpd/trunk/docs/manual/mod/core.html.de
> httpd/httpd/trunk/docs/manual/mod/core.xml.de

I'm sorry, what is that? These changes for the german translation are crap 
(broken automatic translations?!)

I'm going to revert that now.

nd
-- 
package Hacker::Perl::Another::Just;print
q...@{[reverse split/::/ =>__PACKAGE__]}~;

#  André Malo  #  http://pub.perlig.de  #

Re: docs-build as an svn external?

[André Malo]

* Rich Bowen wrote: 


> Is there any particular reason *not* to have docs-build as an svn
> external under the docs/manual directory?
>
> (It's about 12M while the entire httpd-trunk checkout is 223M, so it's
> about a 5% size increase.)

IIRC just that. Most developers (committer or not) don't need it.

nd

Re: svn commit: r910322 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS docs/manual/mod/mod_proxy.xml docs/manual/mod/mod_proxy_connect.xml docs/manual/mod/mod_proxy_http.xml include/ap_mmn.h modules

[André Malo]

* j...@apache.org wrote: 


> Author: jim
> Date: Mon Feb 15 19:54:41 2010
> New Revision: 910322
>
> URL: http://svn.apache.org/viewvc?rev=910322&view=rev
> Log: (empty)

'nough said ;)

nd

Re: [PATCH] Allow AuthZ providers to supply group data to other modules

[André Malo]

* Christian Seiler wrote:

> Hi,
>
> > My approach is thus to provide a simple mechanism within the Apache API
> > which allows any authz module to export group information to other
> > modules. With this mechanism in place, it is possible to change
> > mod_authz_svn in a way that allows it to use a generic group storage
> > that it fetches from any used Apache authz module. The change in
> > mod_authz_svn is of course not the focus of this posting.
>
> Is there nobody who wants to comment on my previous email?

Wrong assumption - I guess it's just the holiday trap ;) If it last for 
another two weeks, just keep posting. People simply overlook stuff from 
time to time and are grateful for reminders.

nd (no time for review here either...)
-- 
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~  # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord(  # André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see;  #  http://pub.perlig.de/ ;

Re: mod_rewrite patch

[André Malo]

* Vincent Bray wrote:

> 2009/12/27 Rich Bowen :
> > A FAQ on the various httpd support channels is "how do I make the query
> > string go away". The answer is that you put "?" on the end of the
> > target URL, which is a bit of a kludge.
> >
> > Attached is a patch that adds a QSD (qsdiscard) flag that does this a
> > little more elegantly. As with my previous email, I wanted some review
> > first before adding Yet Another Rewrite Flag.
>
> Yes please! While the null query string hack works, it is an ugly hack
> to have to foist on people. I've had to suggest it in an apologetic
> manner too many times.

Another point came up while thinking about it: Next time you'll have to 
explain that

RewriteRule foo bar?x=y [QSD]

conflicts and QSD wins (as I read the patch(es)). Dunno if that has to be 
done in an apologetic manner, though ;-)

However, maybe that's the reason it wasn't a flag in the first place.

nd
-- 
die (eval q-qq[Just Another Perl Hacker
]
;-)
# André Malo, <http://pub.perlig.de/> #

Re: mod_rewrite patch

[André Malo]

* Rich Bowen wrote:

> A FAQ on the various httpd support channels is "how do I make the
> query string go away". The answer is that you put "?" on the end of
> the target URL, which is a bit of a kludge.

-1 from the peanut gallery. I think, using an empty query string ("?") is 
not such a kludge and doesn't justify yet another flag. Maybe just 
documenting the issue better would help.

But this opinion is not very strong. Another bit of mod_rewrite overload 
doesn't do that much harm, either ;-)

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

Re: needing some moderators?

[André Malo]

* Philip M. Gollucci wrote: 

> André Malo wrote:
> > * Philip M. Gollucci wrote:
> >> Hi all,
> >>
> >> I sent a message on Friday from my $work address by mistake (yes, I
> >> should add it to the allow list), but it hasn't been moderated through
> >> yet.
> >
> > As I understand it, the list is not moderated anymore for a year now.
>
> Where did the message go then ?

That I don't know. /dev/null?

nd

Re: needing some moderators?

[André Malo]

* Philip M. Gollucci wrote:

> Hi all,
>
> I sent a message on Friday from my $work address by mistake (yes, I
> should add it to the allow list), but it hasn't been moderated through
> yet.

As I understand it, the list is not moderated anymore for a year now.

nd
-- 
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~  # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord(  # André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see;  #  http://pub.perlig.de/ ;

Re: svn commit: r818836 - /httpd/httpd/branches/2.2.x/STATUS

[André Malo]

* Ruediger Pluem wrote:

> On 09/25/2009 02:38 PM, n...@apache.org wrote:
> > Author: nd
> > Date: Fri Sep 25 12:38:45 2009
> > New Revision: 818836
> >
> > URL: http://svn.apache.org/viewvc?rev=818836&view=rev
> > Log:
> > propose another export
> >
> > 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=8188
> >36&r1=818835&r2=818836&view=diff
> > ===
> >=== --- httpd/httpd/branches/2.2.x/STATUS (original)
> > +++ httpd/httpd/branches/2.2.x/STATUS Fri Sep 25 12:38:45 2009
> > @@ -114,6 +114,12 @@
> > 2.2.x Patch:
> > http://people.apache.org/~poirier/PR47754-2.2.x-patch.txt +1: poirier
> >
> > + * mod_rewrite: Add scgi scheme detection. /me completely forgot, that
> > +   mod_rewrite was extended for this as well...
> > +   Trunk Patch:
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/mappers/mod_rewr
> >ite.c?r1=728220&r2=729538 +   (applies with 40 lines offset in 2.2)
> > +   +1: nd
>
> Don't we need to adjust splitout_queryargs in mod_rewrite as well?
> I know that this hasn't happened on trunk, but is this intended or is
> this a bug?

Good point. I think, that's a bug and it's missing for fcgi, too.

nd
-- 
Winnetous Erbe: 

Re: svn commit: r785425 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_dir.c

[André Malo]

* n...@apache.org wrote:

>  static void register_hooks(apr_pool_t *p)
>  {
>  ap_hook_fixups(fixup_dir,NULL,NULL,APR_HOOK_LAST);
> +ap_hook_fixups(fixup_dflt,NULL,NULL,APR_HOOK_LAST);
>  }
>
>  module AP_MODULE_DECLARE_DATA dir_module = {

Without further checking: should we ensure the fixup_dflt is executed after 
fixup_dir? Or is it already (Looks actually random to me)? Maybe it should 
be a late handler instead?

nd
-- 
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook! Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook? Ook. Ook! Ook! Ook? Ook! Ook. Ook? Ook. Ook.
Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook! Ook! Ook!   Ook! Ook.

Re: Using unicode host names with Apache.

[André Malo]

* Graham Dumpleton wrote: 


> Is Apache capable of hosting sites with a unicode host name? Is it
> just a matter of listing the IDNA(RFC3490) variant of the name in
> ServerName or ServerAlias?
>
> Is this the only way it can be done or if configuration files are
> written as UTF-8, could the host name be listed in its UTF-8 form?

Currently only idna.
I'm not sure if we want to load code and tables for idna conversion (which 
version anyway?) into the server just for that config.

nd

Re: Misleading example in Apache 2 doc (fix)

[André Malo]

* Jose Kahan wrote:

[adding d...@]

> I didn't do my homework completely. According to
> RFC 2910, Cookie tokens may be separated by
> white space. The correct regular expression is:
>
> [[
>  SetEnvIf Cookie "language\s*=\s*([a-z|A-Z][a-z|A-Z|-]+)"
> prefer-language=$1 ]]

Also, why are you allowing pipe characters within the language spec? ;-)

How about simply:

language\s*=\s*([a-zA-Z-]+)

?

Maybe

language\s*=\s*([^;,\s]+)

is even better (more flexible). dunno.

nd
-- 
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join   #
 [ $japh =~ /{(.)}/] -> [0] => map $_ -> ()  #André Malo #
=> @japh;# http://pub.perlig.de/ #

Re: svn commit: r729586 - in /httpd/httpd/trunk: CHANGES server/util_script.c

[André Malo]

* Nick Kew wrote: 


> On 8 Jan 2009, at 10:34, Joe Orton wrote:
> > I don't see why 504 is more appropriate than 500 for this case.
> >
> > 504 is specifically defined for cases where the server is acting as a
> > gateway or proxy, which it is not here.  (by the 2616 definitions of
> > gateway and proxy)
> >
> > joe
>
> One might consider the G of CGI a clue.
>
> The fact that the backend is (usually) an application running locally
> on the
> same machine as the webserver doesn't preclude the latter being a
> gateway.
>
> Come to think of it, CGI errors fall into more categories than we allow.
> A misconfiguration is indeed Internal Server Error.  But a script
> that generates
> garbage is an External Server Error, and a 502 response would be in
> order.
> It would be no bad thing to point the finger of blame at broken scripts
> rather than confuse the authors with "internal" errors.

Generally spoken, the message ist mostly not seen by authors, but by users. 
For *them* it's an opaque error (and should be), no matter what.

nd

Re: svn commit: r729538 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy_scgi.xml modules/mappers/mod_rewrite.c modules/proxy/config.m4 modules/proxy/mod_proxy_scgi.c

[André Malo]

* Ruediger Pluem wrote:

> On 12/27/2008 04:07 PM, André Malo wrote:
> > * Ruediger Pluem wrote:
> >> On 12/26/2008 10:41 PM, n...@apache.org wrote:
> >>> URL: http://svn.apache.org/viewvc?rev=729538&view=rev
> >>
> >> Hm. Why this rather complex approach with the request_status hook?
> >> Why not doing the subrequest here or even better just inserting the
> >> file buckets into the brigade right here and be done?
> >
> > The whole point of the sendfile stuff is to free the backend socket as
> > early as possible and leave the rest to the apache. So I'm going out of
> > the proxy loop and handle everything in the request status hook, which
> > runs after the cleanup.
>
> For freeing the backend socket it is IMHO possible to call
> ap_proxy_release_connection first and do the subrequest run afterwards in
> scgi_handler. This avoids the need for using the request_status hook
> which makes the code IMHO more complex then needed.

Hmm. But I still have the internal redirect code there as well. I'd rather 
leave that as-is for the sake of separating concerns. If you ask me, I 
think, it's more simple now ;-)

> > Also I don't want to duplicate the file delivery logic from core
> > (including sendfile, mmap etc), so putting file buckets myself into the
> > stream sounds not like the way to go.
>
> Hm, there isn't that much basic logic to duplicate, basicly
>
> e = apr_brigade_insert_file(bb, fd, 0, r->finfo.size,
> r->pool);
>
> #if APR_HAS_MMAP
> if (d->enable_mmap == ENABLE_MMAP_OFF) {
> (void)apr_bucket_file_enable_mmap(e, 0);
> }
> #endif

Isn't that private config?

nd
-- 
s  s^saoaaaoaaoaaaom  a  alataa  aaoat  a  a
a maoaa a laoata  a  oia a o  a m a  o  alaoooat aaool aaoaa
matooololaaatoto  aaa o a  o ms;s;\s;s;g;y;s;:;s;y#mailto: #
 \51/\134\137| http://www.perlig.de #;print;# > n...@perlig.de

Re: svn commit: r729538 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy_scgi.xml modules/mappers/mod_rewrite.c modules/proxy/config.m4 modules/proxy/mod_proxy_scgi.c

[André Malo]

* Ruediger Pluem wrote:

> On 12/26/2008 10:41 PM, n...@apache.org wrote:
> > URL: http://svn.apache.org/viewvc?rev=729538&view=rev
>
> Hm. Why this rather complex approach with the request_status hook?
> Why not doing the subrequest here or even better just inserting the file
> buckets into the brigade right here and be done?

The whole point of the sendfile stuff is to free the backend socket as early 
as possible and leave the rest to the apache. So I'm going out of the proxy 
loop and handle everything in the request status hook, which runs after the 
cleanup.

Also I don't want to duplicate the file delivery logic from core (including 
sendfile, mmap etc), so putting file buckets myself into the stream sounds 
not like the way to go.

>
> > +url += sizeof(SCHEME); /* keep the slashes */
>
> Why cutting off the scheme?

Good question. I've just tried to find a reason, but I couldn't. Maybe there 
was one a year ago ;-)
I'm gonna remove this line.

Thanks, nd
-- 
print "Just Another Perl Hacker";

# André Malo, <http://www.perlig.de/> #

Re: svn commit: r729543 [1/2] - in /httpd/httpd/tags/2.0.63/docs/manual: ./ developer/ faq/ howto/ misc/ mod/ platform/ programs/ rewrite/ ssl/ vhosts/

[André Malo]

* n...@apache.org wrote:

> Author: nd
> Date: Fri Dec 26 14:03:12 2008
> New Revision: 729543
>
> URL: http://svn.apache.org/viewvc?rev=729543&view=rev
> Log:
> update transformation
>
> Modified:
> httpd/httpd/tags/2.0.63/docs/manual/bind.xml.meta

[..]

Now that was committed in the wrong location. Should I revert it?

nd
-- 
"Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III"

Im Westen was neues: 

Re: [VOTE] Release Apache HTTP server 2.3.0-alpha

[André Malo]

* William A. Rowe, Jr. wrote: 


> Paul Querna wrote:
> > The change fixed velocity.apache.org, but broke www.apache.org.
> >
> > All of this sub-request + output filter stuff started in r620133 kinda
> > needs some more thought.
>
> My thought is that fast_internal_subrequest (which I last refactored, but
> was bogusly introduced for mod_negotiation) must die, now.
>
> Votes?
>
> +1 here to kill fast_internal_subrequest and provide the one fastest
> mechanism that we can safely craft.

+1. wholeheartedly ;-)

nd

Re: missing svn properties

[André Malo]

* Takashi Sato wrote:

> In trunk these files are missing [...]

Go ahead. You don't need to ask for that ;)

nd
-- 
package Hacker::Perl::Another::Just;print
[EMAIL PROTECTED] split/::/ =>__PACKAGE__]}~;

#  André Malo  #  http://www.perlig.de  #

Re: svn commit: r709553 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_authn_core.xml modules/aaa/mod_authn_core.c

[André Malo]

* [EMAIL PROTECTED] wrote:

> Author: chrisd
> Date: Fri Oct 31 13:18:07 2008
> New Revision: 709553
>
> URL: http://svn.apache.org/viewvc?rev=709553&view=rev
> Log:
> Add AuthType of None to support disabling authentication.
> Prevent crash when provider alias created to provider which is not
> yet registered.
> Migrate remaining functionality of mod_authn_default to mod_authn_core.

While this sounds nice...
could you please split such changes into atomic commits? One issue - one 
commit. You also committed docs changes you didn't mention in the log 
message.

I'm not sure if the crash fix shouldn't go into CHANGES.

Thanks.

nd
-- 
>I have tried using ErrorDocument 401, but doesn't work.
   ^
Oh dear.  What does it do - lounge around on the couch all day drinking
beer and watching TV?-- "Kash" und Alan J. Flavell in ciwsu

Re: svn commit: r708462 - in /httpd/httpd/trunk/server/mpm: ./ simple/

[André Malo]

* Paul Querna wrote:

> Ruediger Pluem wrote:

> > This does not work on ANSI C compilers. Declarations need to be at the
> > start of the block.
>
> Then lets not support them.
>
> C90 required that variable decls came before code, but IIRC C99 style
> mid-function declarations should work on pretty much all modern
> platforms, aka anything with GCC or MSVC.

-1.
"IIRC" and "pretty much all modern" are both bad reasons for being 
sloppy ;-)

IIRC ( >:-> ) the AIX compiler actually doesn't like it, but other people 
know that better.

nd
-- 
> Rätselnd, was ein Anthroposoph mit Unterwerfung zu tun hat...

[...] Dieses Wort gibt so viele Stellen für einen Spelling Flame her, und
Du gönnst einem keine einzige.-- Jean Claude und David Kastrup in dtl

Re: svn commit: r670474 - /httpd/httpd/trunk/docs/manual/mpm.html.ko.euc-kr

[André Malo]

* [EMAIL PROTECTED] wrote: 


> Author: martin
> Date: Mon Jun 23 01:26:22 2008
> New Revision: 670474
>
> URL: http://svn.apache.org/viewvc?rev=670474&view=rev
> Log:
> Fix broken link
>
> Modified:
> httpd/httpd/trunk/docs/manual/mpm.html.ko.euc-kr


Uhm, you *do* have seen the comment on top saying:

This file is generated from xml source: DO NOT EDIT

?
nd

Re: [patch] Add IPV6 'specials' flag to mod_rewrite - try 2

[André Malo]

* Ryan Phillips wrote:

> Ryan Phillips <[EMAIL PROTECTED]> said:
> > Jeff Trawick <[EMAIL PROTECTED]> said:
> > > On Mon, Jun 9, 2008 at 9:19 PM, Ryan Phillips 
<[EMAIL PROTECTED]> wrote:
> > > > Ryan Phillips <[EMAIL PROTECTED]> said:
> > > >> So I needed to create some mod_rewrite rules only for IPv6 when
> > > >> httpd is configured for both ipv4 and ipv6 modes.  This patch adds
> > > >> 'RewriteCond IPV6 on' support to the ruleset.
> > > >>
> > > >> I initially tried to see if the incoming socket was APR_INET6, but
> > > >> couldn't find the right structure within the request to query.
> > > >
> > > > Should r->connection->local_addr or remote_addr have the correct
> > > > socket family?  If I try either of these over an IPv4 connection, I
> > > > always get a socket family of IPv6.
> > >
> > > On most platforms, httpd will handle IPv4 connections on an IPv6
> > > socket; the address family will be APR_INET6 and the socket address
> > > will have a special format which indicates that the client is IPv4
> > > (http://en.wikipedia.org/wiki/IPv4_mapped_address).
> > >
> > > Replace "Listen ##" with the combination "Listen 0.0.0.0:##" +
> > > "Listen [::]:##" and you should be able to distinguish between client
> > > connection type by checking the address family (not a real solution).
> > >
> > > The system macro IN6_IS_ADDR_V4MAPPED() can check if an IPv6 socket
> > > address represents an IPv4 client connection.  Apparently APR doesn't
> > > provide an equivalent.
> >
> > Jeff,
> >
> > Thanks for the detailed explanation.  I wasn't aware of this.
>
> Attached is a patch which uses IN6_IS_ADDR_V4MAPPED to see if the client
> is from an IPv4 socket.

You should probably add conditionals for both macros (AF_INET6 and 
IN6_IS_ADDR_V4MAPPED) and deal with non-existance properly. If INET6 is 
missing, you can safely return "off", I think. If IN6_IS_ADDR_V4MAPPED is 
missing - well, then "on" might be right.

Next point - which header files are the macros and structs in? Should we 
include them explicitly? Or are they provided by APR already (and 
officially)?

And finally, "return apr_strdup" should be replaced by "result = ". I know, 
it's probably pasted from the HTTPS variable stuff, but that's not good 
there too ;)

Ah, another last point - is your patch against trunk? It doesn't look like 
it.

nd
-- 
If God intended people to be naked, they would be born that way.
  -- Oscar Wilde

Re: svn commit: r654805 [1/2] - in /httpd/httpd/branches/2.2.x/docs/manual: ./ developer/ faq/ howto/ misc/ mod/ platform/ programs/ rewrite/ ssl/ vhosts/

[André Malo]

* [EMAIL PROTECTED] wrote:

> Author: jim
> Date: Fri May  9 06:35:27 2008
> New Revision: 654805
>
> URL: http://svn.apache.org/viewvc?rev=654805&view=rev
> Log:
> Update doccos

Please update your build system checkout. Yours seems outdated ;)

nd
-- 
Winnetous Erbe: 

Re: mod_deflate Vary header tweak

[André Malo]

* Nick Kew wrote: 


> On Mon, 28 Apr 2008 15:10:14 -0400
>
> "Brian J. France" <[EMAIL PROTECTED]> wrote:
> > I would like to propose a change to mod_deflate that would still
> > send the Vary header if the request is flagged with no-gzip or
> > gzip-only- text/html.
>
> But if no-gzip is set, then the response will not be compressed,
> regardless of the Accept-Encoding header.  So it doesn't vary.

Just to be exact - it *might* vary, depending on how no-gzip is set. 
However, this is still not within the scope of mod_deflate. Thatswhy we 
have provided this sample configuration in the mod_deflate docs together 
with mod_headers.

nd

Re: [PROPOSAL] Time Based Releases

[André Malo]

* Paul Querna wrote:

> This is something I have been thinking about for awhile, and discussed
> with a few other http server people before.
>
> I think that for the 'stable' branch, we should move to time based
> releases.

This would be the place for ", because [...]" ;-)

So, what problem are you trying to solve?

nd
-- 
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~  # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord(  # André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see;  #  http://www.perlig.de/ ;

Re: svn commit: r642971 - in /httpd/httpd/trunk: include/ap_expr.h include/ap_mmn.h server/main.c server/util_expr.c

[André Malo]

* Nick Kew wrote:

> On Mon, 31 Mar 2008 22:24:50 +0200
>
> Ruediger Pluem <[EMAIL PROTECTED]> wrote:

> > >  #define CREATE_NODE(pool,name) do {  \
> > > -(name) = apr_palloc(pool, sizeof(*(name)));  \
> > > -(name)->parent = (name)->left = (name)->right = NULL; \
> > > -(name)->done = 0; \
> > > -(name)->dump_done = 0;
> >
> > Why removing this initializations?
> >
> >   \
> >
> > > +(name) = apr_pcalloc(pool, sizeof(*(name)));
>
> apr_pcalloc is a more concise equivalent:-)

Really? Maybe I'm too theoretical here, but what happens if NULL != (int)0?

nd
-- 
>kann mir jemand sagen, was genau @-Domains sind?
Ein Mythos. Ein Werbetrick. Verarsche. Nenn es wie du willst...

 -- Alexandra Buss und Björn Höhrmann in dciwam

Re: svn commit: r629164 - /httpd/httpd/trunk/support/htpasswd.c

[André Malo]

* [EMAIL PROTECTED] wrote:

> Author: pquerna
> Date: Tue Feb 19 09:05:26 2008
> New Revision: 629164
>
> URL: http://svn.apache.org/viewvc?rev=629164&view=rev
> Log:
> Improve generation of the seed to rand, by using
> apr_generate_random_bytes, rather than the current time as a seed.

Wouldn't it make more sense to drop all that seed and rand hassle and just 
use the apr-random bytes directly as salt (alphabet[byte % len(alphabet)])

nd
-- 
package Hacker::Perl::Another::Just;print
[EMAIL PROTECTED] split/::/ =>__PACKAGE__]}~;

#  André Malo  #  http://www.perlig.de  #

Re: Gentle reminder of outstanding contributed patches

[André Malo]

* William A. Rowe, Jr. wrote:

> Jose,
>
> thank you for the gentle reminder. They really do work :)
>
> I'll review the trunk patch and its test for  in subrequests,
> and propose for backport, since this is all tied into several bug fixes
> and new features I'm working on.  Location walking isn't easy, only a
> small handful of us know that code path, so forgive us for moving slowly.

I still fear that it will break file based subrequest as in (e.g.) 
mod_xsendfile or mod_cern_meta setups. I'm quite short of time though, so 
I'm not able to provide some tests here ATM. Sorry to be of no more help 
here right now. However, it should be said if someone else may get some 
round tuits...

nd
-- 
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join   #
 [ $japh =~ /{(.)}/] -> [0] => map $_ -> ()  #André Malo #
=> @japh;# http://pub.perlig.de/ #

Re: My hacked mod_xsendfile

[André Malo]

* Akins, Brian wrote:

> On 1/25/08 3:51 PM, "André Malo" <[EMAIL PROTECTED]> wrote:
> > I don't recommend doing that as it contains a race condition (the file
> > might be changed in the meantime).
>
> That race is in the default_handler as well, isn't it?

Yes. IIRC there's already a bug report for it.

> (That's one of the reasons I like my approach, we just rely on the
> features/bugs of the core. Fix/enhance that and everyone benefits. )

Huh? I don't see why we should dup the bug.

> > By backend I meant here the script providing
> > the x-sendfile header. That's the only place knowing the behaviour of
> > the file exactly.
>
> In theory, if  backend gives us an x-sendfile, it shouldn't touch it.
> Especially if it's a x-sendfile-temp (lighttpd calls this something
> strange).

Yes, if it's temp you're right. In the other case there's no guarantee given 
to the webserver. X-Sendfile should just take the file and apply the rest 
of the headers sent by the backend. Everything doing else lessens its 
usefulness.

nd
-- 
sub the($){+shift} sub answer (){ord q
[* It is always 42! *]   }
   print the answer
# André Malo # http://www.perlig.de/ #