@apache_httpd Twitter account?
Who's responsible for the @apache_httpd account? -- Rich Bowen rbo...@rcbowen.com Shosholoza
Re: Thinking about adding a link to modules.a.o on our web site.
Links don't imply endorsement (although maybe we need to say that explicitly), so I think that links are a very good thing when they help real people solve real problems. So, +1 On May 7, 2013, at 6:41 AM, Daniel Gruno wrote: > Hi all, > I did some talking with Jim and Rich (or was it Rainer, I forget) during > ApacheCon, in which we agreed that we need to plug our modules directory > some more. I totally forgot all about this, but since it's never too > late to get something like this done, I am now contemplating adding a > link from our web site, httpd.apache.org, to modules.apache.org in the > navigation bar on the left side. > > I don't see this as a big issue that needs a vote, so I'll let it simmer > for a while (standard 72 hours) and assume lazy consensus if I hear no > objections from you lot. > > With regards, > Daniel. -- Rich Bowen rbo...@rcbowen.com Shosholoza
Re: Interpolating %{variables} in all directives
On Apr 18, 2013, at 11:09 AM, Igor Galić wrote:
> From an IRC conversation in #httpd and #httpd-dev emerged the
> idea to interpolate %{variables} in all directives.
> According to sf we have somewhere a ~10 line code fragment
> which does that without much overhead (not benchmarked) when
> interpolating and with hardly any (short-circuit) when not.
>
> I think it would be a good idea to allow for this to be used
> in all directives (across all modules) it makes for immensly
> more readable configurations because:
>
> Example:
>
># default vhost redirecting every HTTP vhost to HTTPS:
>
>Redirect / https://%{HTTP_HOST}/
>
>
>
> Another example might be something "more advanced" like:
>
># group specific authorization:
>[^/]+).*">
>Require group %{group}
>
This would be lovely, and make us as cool as nginx.
Problems to address include conflicts with mod_macro, mod_rewrite, and any
third-party module which might do variable fu.
Having the interpolation ignore stuff starting with Rewrite* or in a mod_macro
definition seems simple enough. Having a generic way for a third-party module
to say "don't interpolate me, man!" could be handy too.
--
Rich Bowen
rbo...@rcbowen.com
Shosholoza
Re: [Vote] Overhaul modules.apache.org
+1 On Jan 25, 2013, at 8:21 AM, Daniel Gruno wrote: > [ ] +1: I support this proposal > [ ] 0: I don't care > [ ] -1: I don't support this proposal, because... -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: mod_macro has been added
On Jan 20, 2013, at 5:45 AM, Fabien wrote: > > Hello devs, > > I've been given the go to add mod_macro to httpd trunk, see r1435811. > > The module is in modules/core. There are English and French documentations > and extensive non regression tests. The module is compiled in with "most". It > is fully independent, i.e. I have not changed or modified core stuff for the > module. I think it is safe and may be considered for backporting to 2.4, as > well as the "Warning" directive added some time ago. Forwarding to docs for the few folks that pay more attention there than here. > > I'm not sure about how to advertise the use of the module. Possibly something > in the standard default configuration, maybe some carefully designed example > macros could be defined and use here and there to show how great that can be? > Lets put something in conf/extras with an as-simple-as-possible example in it, and a pointer to the docs. > Also, maybe some mention of the module should appear in "configuring" and > "sections" in the documentation? I envision something, eventually, along the lines of the Rewrite recipe-style docs with howtos for various scenarios. I haven't yet looked through the docs that are already provided, but will do so this week and work on integrating it into the rest of the docs where it is relevant. I expect that the vhost section is an obvious entry point, as that's where I see mod_macro used most extensively in the wild. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: [VOTE] accept mod_macro as standard module in httpd
On Jan 2, 2013, at 9:06 PM, 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 -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: mod_macro into apache ?
On Nov 11, 2012, at 3:57 AM, Fabien wrote: > I have developed and maintained a small module called "mod_macro" since 1998. > It is currently available at: > > http://people.apache.org/~fabien/mod_macro/ > > I started it one day as was fed up with copy-pasting configuration directives > from one virtual host to the next and one directory to the next. It includes > Define/Use of configuration macro, as well as Error/Warning macros. The code > is fairly stable (14 years:-). > > I would like to donate the code so that it could be integrated with apache as > a standard module. +1 That would make me very happy. It's one of the modules that I often in my talks encourage people to install immediately and think of as a standard module. It would be awesome if it really was. -- Rich Bowen rbo...@rcbowen.com Shosholoza
Re: svn commit: r1396838 - /httpd/httpd/trunk/docs/manual/mod/mpm_winnt.xml
On Oct 12, 2012, at 5:38 AM, Rainer Jung wrote: > Typo Alarm: Sorry. Fixing. -- Rich Bowen rbo...@rcbowen.com Shosholoza
Re: [VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch of the httpd docs
> > > [ x ] +1: Adopt the comments.a.o system in the 2.2 and 2.4 branch of docs > [ ] 0: I don't care > [ ] -1: Don't adopt the system, because > -- Rich Bowen rbo...@rcbowen.com
Re: Comment system, take two and a half
On May 29, 2012, at 5:04 AM, Graham Leggett wrote: > On 29 May 2012, at 8:50 AM, Daniel Gruno wrote: > >>> Each branch different, 2.2 & 2.4 have some big differences between >>> them in various areas. My 2 cents anyway. >> What I'm perhaps more curious to get sorted out is whether we should >> consider the trunk and the 2.4 documentation separate entities, or >> whether they should be linked, comment-wise. Currently, they are pretty >> much identical, but in the future it may be a good idea to keep them >> separate as we move towards 2.5/2.6. > > My gut feel is that trunk shouldn't have comments at all - trunk is fluid, > and changes without warning. Comments are very likely to get stale and become > more of a problem than a help. I've come around to thinking that they should be separate. I think it'll be useful to have comments on trunk, but, particularly on trunk, there needs to be no expectation that comments will stick around for any time at all. In my view of this, comments should *not* be considered a permanent part of the document. Either they get incorporated into the document itself, or they get flushed. I really don't want to see comments sticking around forever on a doc. I consider them to be more of a means of contributing to the doc effort. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: Comment system, take two
On 2012 5 21 17:04, "Daniel Gruno" wrote: > > In light of recent concerns about the Disqus system, I've taken it upon > myself to figure out an alternative we can use for adding comments to > our pages. And so, through the better half of a day, I worked on > creating a new system that is without any evil tracking mechanisms of > any sort except for what people themselves will allow - that is, only > information that is willingly entered will be stored, no IPs or such. > > The result (thus far) can be seen at a small test page I made for the > http project at http://c.apaste.info/httpd.html - feel free to give it a > test spin and see what you like. > Very cool, Daniel. Thanks for this work. +1 to moving forward to testing it in some portion of the trunk docs.
Re: [VOTE] CMS site migration
On May 8, 2012, at 3:14 PM, Joe Schaefer wrote: > [ +1 ] to migrate httpd-site to the CMS -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: [DISCUSS] CMS site migration
Joe, thanks for your work on this, and your patience through the process. --Rich On May 6, 2012, at 5:39 PM, Joe Schaefer wrote: > Over on docs@ one of the recent conversations was > around moving the site documentation to the CMS, > starting first with the httpd site as a testbed. > After several hours of hacking on the site that > has now been accomplished, so we'd please like everyone > to review and comment on the httpd staging site now > available at > > http://httpd.staging.apache.org/ > > which is perfectly compatible with the CMS's bookmarklet. > There are a few remaining syntax/style issues that need > addressing, but otherwise the content has been successfully > migrated from xdoc to markdown. > > The sooner we can push this work into production the > less hassle it will be to keep the xdoc and content > trees in sync using two separate build systems. > > After a few days have passed if there are no outstanding > issues remaining I plan to ask for a VOTE to finish the > migration of httpd-site to the CMS. Thanks in advance > for your consideration! > > > - > To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org > For additional commands, e-mail: docs-h...@httpd.apache.org > -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: [Vote] Add commentary system to httpd docs
On 2012 5 4 15:04, "Igor Galić" wrote: > > > > [+1] Add commentary system to the trunk documentation. > > > This may be worth a separate thread, but I'll just ask > it here, before I forget about it: > > Any chance we'll see a backport of this to /current/ ? > If so, will we display the same comments as in /trunk/ ? > I would assume that if the test is successful we would expand it to current and 2.2. As to whether each branch has their own comments, I think they probably should, but thats still to be decided. -- Rich Bowen rbo...@rcbowen.com
Re: [Vote] Add commentary system to httpd docs
On May 4, 2012, at 9:58 AM, Daniel Gruno wrote: > [+/-1] Add commentary system to the trunk documentation. Obviously, I'm +1 on this, as one of the folks who's been gently pushing for it for years. This is something that the PHP docs do right. Integrating comments into the documentation is a pretty big undertaking, but in the long run will make the docs more what our audience needs and is asking for. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: Moving on
On Apr 20, 2012, at 10:15 AM, Dr Stephen Henson wrote: >> But with no mention of swimming pools full of puppies or Lord >> Palmerston? Of course no one gets it... >> >> > > I was either that, bicycles or asking if someone had passed their driving > test. Thank you, both of you, for further illustrating my point. Now, ask yourself whether your mutual chuckle was worth making most of the rest of us feel like we were outside some shared joke. For myself, I'm not sure I care. I'm somewhat used to being a foreigner in a culture of shared jokes, and one learns to ignore it. But some people find it very alienating, and this is a loss to all of us. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: Moving on
On Apr 20, 2012, at 7:47 AM, Dr Stephen Henson wrote: > Personally I like humorous or thought provoking comments in source files it > shows the human side of the authors. > > If we want to make the whole thing bland and faceless then so be it. I think > it > will be lessened as a result. > > If that's "sentimental" then I suppose I am. > > I'd like to hear other peoples opinions on this. My comment on this is that humorous comments can be good, and they can be intimidating and confusing - particularly for people who don't get the joke, and in particular for those whose first language is not English or other related languages or whose culture is not conducive to humor in a technical context. People who are in the know, and get the jokes, don't see this as a problem because, well, they get the joke. I'm reminded of the Python documentation, where every other thing is a monty python joke. All well and good if you get the joke, but if you don't, it's just baffling. This separation often occurs between those of us from either the US, or western european nations, and people from the rest of the world (i.e., most of humanity.) and serves, in part, to perpetuate an under-representation from those cultures. (Not sure what's up with those Sri Lankans! ;-) Humor in the code, and in the documentation, does indeed provide a human side, and inside jokes are something that binds together communities. However, it can also be the thing that makes people reluctant to change existing code, because it's so clearly "owned" by one particular person. This is something of a soap-box for me, so I suppose I'm not speaking just about mod_ssl, but documentation/comments in general. Comments like: Abandon all hope, ye who read this code. Don't believe the name: and Open-Source Software: generous programmers from around the world all join forces to help you shoot yourself in the foot for free. and Where's the spoons? Where's the spoons? Where's the bloody spoons? for example, contribute nothing to the code, and serve to confuse, intimidate, and generally discourage people who want to contribute to the effort, and aren't inside the joke yet. It may be that they should just get over it and that I'm being overly sensitive, but, well, you asked for other opinions. That's mine. This simply one small example, in one project, where I see this problem. It's not an enormous problem, and I'm sure that most folks don't even think it's a problem. But it's something that I've been thinking about for a few years. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: http-mpm.conf.in versus docs and defaults
On Mar 28, 2012, at 1:34 PM, Daniel Gruno wrote: > Being a new committer and, basically, just a documentation committer, I feel > that I must bring this before the dev@ list before proceeding any further. > There appears to be a mismatch between the mpm defaults in the configuration > and the documentation surrounding it as well as the header definitions. An > example is the worker and event mpm, where the configuration defines them so: > > StartServers 2 > MinSpareThreads 25 > MaxSpareThreads 75 > ThreadsPerChild 25 > MaxRequestWorkers 150 > > However, in both the documentation and the headers, these values can be read > or calculated as: > > StartServers 3 > MinSpareThreads 75 > MaxSpareThreads250 > ThreadsPerChild 25 > MaxRequestWorkers 400 > > From what I can gather with my IRC chats with Igor Galic, this has been > discussed quite a while back, and the consensus was to adopt these new values > as default, but somehow it did not make it to the http-mpm.conf.in file. > I have been asked to change the values in the conf.in file, but I'm very > unsure if it is merited, so I therefor ask you, oh great people of the dev@ > list, to give me an answer as to whether these new values should be adopted > or not. The current stance we have taken in discussions regarding these > values is that there is a difference between default configuration value and > the default values hard-coded into the server, but it can seem a bit silly to > use that explanation at times. My opinion on this is that the default shipped configuration file should match the in-code default values. Some of the out-of-sync default config file values are historic, others are simply errors. In either case, they should be brought into sync with the built-in defaults. So, yeah, do it. --Rich (One voice among many)
Re: [RE-VOTE #2] adoption of mod_policy subproject
On Mar 2, 2012, at 2:27 PM, William A. Rowe Jr. wrote: > On 3/2/2012 12:28 PM, William A. Rowe Jr. wrote: >> A proposal to adopt mod_policy is attached. >> >> [X] Option 1: adopt as trunk module > > Provided that mod_policy is droped into modules/testing > .../debugging or .../experimental Ditto. Option 1, in experimental. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: [RE-VOTE] adoption of mod_firehose MODULE
On Mar 1, 2012, at 4:02 PM, Greg Stein wrote: > Modules do not have to be tested *before* they appear in trunk. That's > putting the cart before the horse. Part of the development process > (while in trunk) is doing the testing portion. And hey... if it never > gets tested, then it gets marked as "experimental" and we all move on. This is why I'm not understanding why this particular module (or set of modules) is getting this level of debate and scrutiny. We're talking about adding them to trunk, not in a release. Presumably we wouldn't put them in a release if there was a problem with them. I've often thought that modules like, say, mod_ftp, would have a much greater chance of being successful if they were in trunk rather than it being several additional steps to obtain. I'm +1 to having this in trunk, but am voting based on the community aspects, rather than the technical ones. I figure the technical aspects will work themselves out in trunk ... or they won't, and we'll drop it from a release branch. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: [proposed] remove docs/1.3/
On Feb 26, 2012, at 12:52 PM, Nick Kew wrote: >> 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. > > WTF? > > That's what robots.txt is for! Surely we can use that to stop indexing 2.0 > as well as 1.3? Maybe even 2.2 once 2.4 is windows-ready and in the distros? The rel canonical thing is a way to actively update the Google index for a particular page and search term, and has been very effective in updating certain searches. For example, searching Google for "rewriterule" has long given the 1.3 Rewrite Guide, but within 24 hours of adding a rel canonical tag, it started pointing to the 2.2 mod_rewrite docs as the top hit. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: [proposed] remove docs/1.3/
On Feb 27, 2012, at 2:16 PM, André Malo wrote: > > 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.) I started working on this a while back. It's more work than you'd think, because the HTML files aren't generated from source, like in the 2.x docs, but are static HTML files, with individual differences. I was part way through this when I changed jobs, and the changes were lost with my work laptop. D'oh! So I need to start that effort over again. > > - put robots=noindex into the documents and/or add a line to the robots.txt Yeah, we can do that too. > > - we could probably remove 1.3 docs from the navigation I thought we'd already done that. Apparently not. Doing it now. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: [proposed] remove docs/1.3/
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
Re: Error codes
On Nov 30, 2011, at 3:23 AM, HyperHacker wrote: > > Any reason *not* to use 5 digits? The extra character, or using hex, seems worth the future flexibility. We want to be able to assign new codes, rather than reusing old ones, when error messages change in future versions. Allocating 50 messages to mod_foo might be fine for now, but in httpd version 4.8 we may have all new messages. Not sure we can adequately determine how many is enough to allocate. -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: Error codes
On Nov 29, 2011, at 6:30 PM, Stefan Fritsch wrote: > Currently my scripts produces: > > http://people.apache.org/~sf/error-msg-numbers.diff > http://people.apache.org/~sf/error-msg-numbers.list > > This is level info and up, but that is easily changed. > > The script still misses all occurences where the format string is > split into several parts (e.g. over several lines), where the loglevel > is not constant but a variable, and possibly some others. > > Are other folks comfortable with going this way? Add it to 2.4? +1 -- Rich Bowen rbo...@rcbowen.com :: @rbowen rbo...@apache.org
Re: Proposal: error codes
On Nov 27, 2011, at 12:58, Rich Bowen wrote: > > Thanks for the suggestion of the odd format. That seems very reasonable. Clearly I need to stop writing email on my phone. The CODE format.
Re: Proposal: error codes
On Nov 27, 2011, at 12:14, Stefan Fritsch wrote: > Yes, that would be a good idea and I agree with Daniel that we should > use a distinct prefix or format. We currently have around 2700 calls > to *_log_?error in trunk, so a 4-digit number should be ok. Together > with for example AH as prefix for "Apache HTTPD" this would result in > numbers like AH0815 which don't seem to cause many hits on google. > > As a first step, one could simply manually add the error code to the > format strings of those messages that frequently appear in support > requests. This would be non-disruptive for 2.4 and could even be done > in some future 2.2.x version, if someone is willing to do the work. Yes, I'm willing to do the work, as are some folks on the docs list. I expect we'd start drafting the doc in the wiki and move it to the formal docs once it's more fully done. Thanks for the suggestion of the odd format. That seems very reasonable.
Re: Icons for 2.4
On Nov 27, 2011, at 10:49, Rainer Jung wrote: > On 27.11.2011 10:50, Stefan Fritsch wrote: >> Hi, >> >> docs/icons/apache_pb2* contain the version number (2.2), in the case >> of docs/icons/apache_pb2_ani.gif it's even an animation. >> >> Any volunteers for changing these to 2.4? > > Anyone knows the right or at least a similar font? No, but I remember that we discussed this around the 2.2 release so you might be able to find something in the archives.
Proposal: error codes
At Apachecon several of us were discussing how error messages could be made more helpful without making them paragraphs. Two suggestions were made - adding a URL to the message or adding a number/code to each error that would then be looked up for more information. Any thoughts on 1) the wisdom of this and 2) the method of assigning codes? I've long considered error messages to be documentation and would live to see the log files be one step more helpful. -- Rich Bowen rbo...@rcbowen.com
Re: mod_proxy_html
On Oct 13, 2011, at 12:12 PM, Andrew Oliver wrote: > nonbinding +1 for it being bundled. That makes life a tad easier in > various environments where I have to configure mod_proxy... Agreed (although I see I'm probably too late to be relevant). As an end-user and customer-support guy, having it bundled makes everything that much easier. Having it a separate module makes it no more convenient than it already is as a third-party thing. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: Pushing for httpd 2.4.0 GA
On Sep 19, 2011, at 8:58 AM, Jim Jagielski wrote: > > On Sep 18, 2011, at 6:17 PM, Rich Bowen wrote: >> - mod_lbmethod_bybusyness >> - mod_lbmethod_byrequests >> - mod_lbmethod_bytraffic > > Do we really need full doccos for these "sub" modules? > No matter what, these would be easy to do since mod_proxy > and mod_proxy_balancer pretty much describe them anyway ;) Someone's created enough of a doc to say what the module is after someone spots it in httpd -M and wants to know what it is. I'll update them to not promise more. That is, they currently say "This document is still under development", but I think what's there is probably sufficient for the purpose. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: Pushing for httpd 2.4.0 GA
On Sep 18, 2011, at 7:16 PM, Nick Kew wrote: >>> >>>- mod_socache_dbm >>>- mod_socache_memcache >>>- mod_socache_shmcb >> >> Not sure about socache, but docs are definitely needed, because you need >> socache for mod_ssl session cache (which we also need to mention int the >> mod_ssl docs). > > These modules are implementations of an abstraction, and probably > don't want standard module pages. Like mod_proxy_foo backends. Excellent. I wondered if they were in that category. The list was produced from a simple grep. I'll remove those from my list, and see if I can find any that I missed, or which are new since I made the original list. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
PATCH: mod_log_config, CookieLog
The CookieLog directive has been documented as deprecated since mod_log_config
was introduced, back in the 1.2 days. Any objection to axing it?
Index: docs/manual/mod/mod_log_config.xml
===
--- docs/manual/mod/mod_log_config.xml (revision 1172391)
+++ docs/manual/mod/mod_log_config.xml (working copy)
@@ -361,23 +361,6 @@
-CookieLog
-Sets filename for the logging of cookies
-CookieLog filename
-server configvirtual host
-
-This directive is deprecated.
-
-
-The CookieLog directive sets the
-filename for logging of cookies. The filename is relative to the
-ServerRoot. This directive is
-included only for compatibility with mod_cookies,
-and is deprecated.
-
-
-
-
CustomLog
Sets filename and format of log file
CustomLog file|pipe
Index: modules/loggers/mod_log_config.c
===
--- modules/loggers/mod_log_config.c(revision 1172391)
+++ modules/loggers/mod_log_config.c(working copy)
@@ -31,9 +31,6 @@
*Log to file fn with format given by the format
*argument
*
- *CookieLog fnFor backwards compatability with old Cookie
- *logging module - now deprecated.
- *
* There can be any number of TransferLog and CustomLog
* commands. Each request will be logged to _ALL_ the
* named files, in the appropriate format.
@@ -1284,11 +1281,6 @@
return add_custom_log(cmd, dummy, fn, NULL, NULL);
}
-static const char *set_cookie_log(cmd_parms *cmd, void *dummy, const char *fn)
-{
-return add_custom_log(cmd, dummy, fn, "%{Cookie}n \"%r\" %t", NULL);
-}
-
static const char *set_buffered_logs_on(cmd_parms *parms, void *dummy, int
flag)
{
buffered_logs = flag;
@@ -1311,8 +1303,6 @@
"the filename of the access log"),
AP_INIT_TAKE12("LogFormat", log_format, NULL, RSRC_CONF,
"a log format string (see docs) and an optional format name"),
-AP_INIT_TAKE1("CookieLog", set_cookie_log, NULL, RSRC_CONF,
- "the filename of the cookie log"),
AP_INIT_FLAG("BufferedLogs", set_buffered_logs_on, NULL, RSRC_CONF,
"Enable Buffered Logging (experimental)"),
{NULL}
--
Rich Bowen
rbo...@rcbowen.com
rbo...@apache.org
Re: Pushing for httpd 2.4.0 GA
On Sep 18, 2011, at 5:12 PM, Jim Jagielski wrote: > > On Sep 17, 2011, at 10:02 PM, Rich Bowen wrote: > >> >> On Sep 15, 2011, at 9:01 AM, Jim Jagielski wrote: >> >>> I plan on push for a GA in Oct (of this year)… >>> >>> The only 2 showstoppers I see as "reasonable" are the >>> documentation ones and the mod_fcgid one. >> >> Could you enumerate what you feel is lacking in the documentation? I know of >> several modules that are effectively undocumented, and a few more that have >> minimal, but insufficient documentation. I'd like to hear your take on this. >> As always, I'm willing to whatever I can on the editing, formatting, etc, >> side of things, but the raw info needs to come from somewhere. Please let me >> know where I can be of assistance. >> > > Just the possible fact that some modules may not have doccos… > Not sure if that is even the case (yet), but if there are mod's > w/o docs, then we can't in good conscience ship the mods. > My current list is: - mod_serf - mod_watchdog - mod_heartbeat - mod_heartmonitor - mod_lbmethod_bybusyness - mod_lbmethod_byrequests - mod_lbmethod_bytraffic - mod_lbmethod_heartbeat - mod_socache_dbm - mod_socache_memcache - mod_socache_shmcb - mpm_simple However, I will readily admit that I haven't had much time to work on docs the last month or two, so some of these many have been documented since then, and there may be others that I'm missing. There's also mod_lua, which has many directives documented with "...", and I suspect that there are other modules in this same state. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: Documentation clarification: ErrorLogFormat
On Sep 17, 2011, at 10:56 PM, Rich Bowen wrote: > In the documentation for the ErrorLogFormat directive, log format strings are > given as, for example, %...A > > What does the ... signify? > > It's not clear to me either from the doc (which doesn't mention it) or the > source what that's supposed to signify. My apologies. It *is* mentioned in the documentation. It's where the modifier (-, +, or a number 1-15 signifying the log level) goes. I'll add some examples in there so that people, like myself, who can't read, don't overlook it. :) -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Documentation clarification: ErrorLogFormat
In the documentation for the ErrorLogFormat directive, log format strings are given as, for example, %...A What does the ... signify? It's not clear to me either from the doc (which doesn't mention it) or the source what that's supposed to signify. Thanks for any light anyone can shed on this for me. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: Pushing for httpd 2.4.0 GA
On Sep 15, 2011, at 9:01 AM, Jim Jagielski wrote: > I plan on push for a GA in Oct (of this year)… > > The only 2 showstoppers I see as "reasonable" are the > documentation ones and the mod_fcgid one. Could you enumerate what you feel is lacking in the documentation? I know of several modules that are effectively undocumented, and a few more that have minimal, but insufficient documentation. I'd like to hear your take on this. As always, I'm willing to whatever I can on the editing, formatting, etc, side of things, but the raw info needs to come from somewhere. Please let me know where I can be of assistance. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: EOL for 2.0
On Sep 16, 2011, at 11:59 AM, William A. Rowe Jr. wrote: > On 9/16/2011 12:51 AM, Issac Goldstand wrote: >> IIRC, we talked about making 2.0 EOL when we make the next release, but >> I don't think we ever formalized the decision. >> >> Does anyone have comments for or against announcing 2.0 End-Of-Life at a >> set time (say 3 months) following the release of 2.4? > > Yes, I'd prefer we set a 12 month sunset on 2.0 in conjunction with the > 2.4 release, not 3 months later when nobody is paying attention. +1. While I'd like to be rid of it earlier, I think 3 months is too fast. 12 months may be too long, but we lose nothing by setting it there rather than too short. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: MaxRanges
On Sep 6, 2011, at 8:41, Eric Covener wrote: > On Tue, Sep 6, 2011 at 8:31 AM, Rich Bowen wrote: >>> e.g. MaxRanges none | 0 (none) | unlimited | n>=1 >> 0 means unlimited - this is consistent across all of our configuration >> directives. Please let's not change that here. It's what folks expect it to >> mean. Let's not surprise them. > > How about rejecting 0 if it's too loaded/ambiguous? Accept > "unlimited", "none" and n>0 ? +1
Re: MaxRanges
0 means unlimited - this is consistent across all of our configuration directives. Please let's not change that here. It's what folks expect it to mean. Let's not surprise them. On Sep 6, 2011, at 8:09, Eric Covener wrote: > On Tue, Sep 6, 2011 at 7:34 AM, Jim Jagielski wrote: >> From the code, MaxRanges 0 means unlimited… >> >> Is that what we want? I can envision some use-cases where >> an admin may want to disable ranges totally and MaxRanges >> is really the place to do that. >> >> How about a setting <0 means unlimited? (yes, this involves some >> code and logic changes)... > > No magic reasons for current state here, I'd suggest teaching it to > take strings as well as numbers so users don't need to know 0/-1 > significance > > e.g. MaxRanges none | 0 (none) | unlimited | n>=1
Re: Question and request for comments on patch
On Jul 19, 2011, at 7:44 PM, Daniel Ruggeri wrote: > All; > I am attaching a patch that will allow for a comma separated list of > directives permissable for override. This is something that has been requested by folks on the users mailing list, and on IRC, as far back as I've been watching. Seems like a great improvement. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: svn:externals for docs build
> > > > I find 98M in a clean checkout. (69M of that belong to the docs already). Wow. I had no idea the docs were that much of it. > > maybe we should move out the docs entirely -1 Putting any extra obstacles in front of anyone writing a doc is unwise. I don't honestly think anyone minds checking out the repo at the current size. Have we heard complaints?
Re: svn:externals for docs build
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. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: svn:externals for docs build
On Jun 29, 2011, at 10:30 AM, André Malo wrote:
> 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.
[rbowen@Rocinante:apache/httpd-trunk]$ cd docs/manual
(06-29 10:38)
[rbowen@Rocinante:docs/manual]$ du -ksh build
(06-29 10:38)
13Mbuild
[rbowen@Rocinante:docs/manual]$ cd ../../
(06-29 10:38)
[rbowen@Rocinante:apache/httpd-trunk]$ du -ksh ./
(06-29 10:39)
249M./
[rbowen@Rocinante:apache/httpd-trunk]$ perl -le 'printf( "%.02f%%\n", 13/249 *
100 );'
(06-29 10:42)
5.22%
Doesn't seem like it's a terribly significant addition.
--
Rich Bowen
rbo...@rcbowen.com
rbo...@apache.org
Re: "RewriteRule ... /$1" considered harmful
On May 2, 2011, at 12:04 AM, Eric Covener wrote: > I took a pass at the doc to make the stuff we're discussing a bit more > explicit which might help the discussion/deprecation too. > > http://people.apache.org/~covener/patches/rewrite-substitution_clarity.diff +1 to changes. -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: svn commit: r1092797 - /httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml
I've fixed this in the docs, but wanted to verify that the actual behavior is in fact the desired behavior. The docs state (stated until today) that the domain argument to the CO RewriteRule flag would default to the current domain. This is not the case. Omitting the domain argument results in: 74.131.224.250 - - [15/Apr/2011:20:01:06 +] [embowen.com/sid#7ff55cfc54f8][rid#7ff55d254168/subreq] (1) pass through /index.php (Test case: RewriteRule ^ - [CO=foo:bar]) whereas with the domain, it results in: 74.131.224.250 - - [15/Apr/2011:20:01:33 +] [embowen.com/sid#7f02acd994f8][rid#7f02ad0180e8/initial] (5) setting cookie 'foo=bar; path=/; domain=embowen.com' 74.131.224.250 - - [15/Apr/2011:20:01:33 +] [embowen.com/sid#7f02acd994f8][rid#7f02ad0180e8/initial] (1) pass through /index.php (Test case: RewriteRule ^ - [CO=foo:bar:embowen.com] Granted, it seems to be a good idea to always set the domain, and in fact I had never encountered this "bug" before because I always do set the domain. On Apr 15, 2011, at 4:06 PM, rbo...@apache.org wrote: > Author: rbowen > Date: Fri Apr 15 20:06:53 2011 > New Revision: 1092797 > > URL: http://svn.apache.org/viewvc?rev=1092797&view=rev > Log: > Whether it's intentional or not, the hostname/domainname argument to the > RewriteRule CO flag is in fact required. Cookies are not set without it. > (via Matthew Sporleder) > > Modified: >httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml > > Modified: httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml > URL: > http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml?rev=1092797&r1=1092796&r2=1092797&view=diff > == > --- httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml (original) > +++ httpd/httpd/trunk/docs/manual/mod/mod_rewrite.xml Fri Apr 15 20:06:53 2011 > @@ -1100,7 +1100,7 @@ cannot use $N in the substi > > cookie|CO=NAME:VAL > Sets a cookie in the client browser. Full syntax is: > - > CO=NAME:VAL[:domain[:lifetime[:path[:secure[:httponly] > details ... > + > CO=NAME:VAL:domain[:lifetime[:path[:secure[:httponly > details ... > > > > > -- Rich Bowen rbo...@rcbowen.com rbo...@apache.org
Re: PHP5.3.6
On Mar 18, 2011, at 12:07 PM, Mladen Turk wrote: > On 03/18/2011 04:55 PM, Rich Bowen wrote: >> >> On Mar 18, 2011, at 11:48 AM, Mladen Turk wrote: >> >>> On 03/18/2011 04:43 PM, Jeff Trawick wrote: >>>> >>>> what if we add text to our download that says that official PHP >>>> binaries for Windows starting with 5.3.6 no longer work with our >>>> stable-ABI builds >>>> >>> >>> +1 >> >> Doing that without suggesting an alternative seems discourteous both to >> these Windows users and to the PHP community. >> > > Alternative would be "We are looking for a solution". > We don't need to give up before even trying. > > I gave the alternative by using winddk compilers. > If compiled using those tools it works perfectly with both old and new php > versions. > > Look at thread few weeks ago. > Bill said he will use VS2010, so given that PHP uses VS2008 > we are again in endless loop of catching one other's version. > > Like I suggested, we could avoid linking to msvcrtXX.dll > which will allow any third party plug-in to work seamlessly. If that's something that we're actively moving towards, that would be great. Thanks. -- Rich Bowen rbo...@rcbowen.com
Re: PHP5.3.6
On Mar 18, 2011, at 11:48 AM, Mladen Turk wrote: > On 03/18/2011 04:43 PM, Jeff Trawick wrote: >> >> what if we add text to our download that says that official PHP >> binaries for Windows starting with 5.3.6 no longer work with our >> stable-ABI builds >> > > +1 Doing that without suggesting an alternative seems discourteous both to these Windows users and to the PHP community. -- Rich Bowen rbo...@rcbowen.com
Re: PHP5.3.6
On Mar 18, 2011, at 10:55 AM, Jeff Trawick wrote:
>
> I don't think we should ever point to third party httpd downloads.
> Let those offering binaries compete in the same way as Ubuntu, Fedora,
> etc.
> I think in general that the Apache-on-Windows user community offers up
> a relatively small amount of sacrifice (contributed effort per size of
> community) at the same time that the platform has a large number of
> technical considerations, and I cannot suggest that we (really, Bill
> and tiny number of others) do more work on their behalf.
I'm not suggesting that Bill do any more on their behalf. I'm suggesting that
we embrace the huge effort that Stefan and the ApacheLounge folks have done,
and direct people there. It seems that everybody stands to benefit if we
improve relations with that community, or, at the very least, acknowledge their
existence.
What would it take, from our side or from Stefan's, to make it ok for us to say
"go here for Windows binaries"? It surely seems that this would be a big win
for both of us.
> For open source on Windows in general, I think changes to make it more
> practical for "normal" users to build open source is what will
> ultimately improve the overall Windows situation (it is an anomaly
> that we have such a discussion of binaries), as it enables a more
> fruitful conversation ("can you try this patch?" vs. getting stuck at
> "you gave me this binary and it fails") and will facilitate the
> involvement of more would-be developers. I understand that MS has
> done a lot of work to make it more feasible to build PHP + extensions
> on Windows. This doesn't help at all the VC6 issue, but it is a big
> improvement for the long term. (I wonder if MinGW support by the
> various projects is viable for random users, or if a lot more effort
> is required to make it smoother.)
That sounds good, I suppose, but doesn't actually help any of our actual
customers today, or any foreseeable tomorrow.
--
Rich Bowen
rbo...@rcbowen.com
PHP5.3.6
I wanted to be sure that folks are aware of what's going on in the Windows/PHP world. I know that, in one sense, it's not our problem, but it *feels* like our problem to me, and to many of our users. PHP5.3.6 was just released, and the Windows binaries are built with VC9, meaning that it won't work with our Windows binaries. I know that it's been discussed before, and there's a plan to move to VC9, but as of last week, the official PHP build doesn't run with the official Apache httpd build. The PHP website recommends that folks use the Apache Lounge build. This sucks. It sucks that our users have to jump through additional hoops. It sucks even more that there wasn't (or at least, it appears to me that there wasn't) conversation between the two communities prior to this happening. The folks in php-land are aware that it's a problem, but don't see to really think that it's *their* problem. For our part, we seem to be unaware that anything happened. I don't know that the relationship between Apache httpd and php communities is anybody's *fault*, but it's long struck me as a great shame that there isn't closer cooperation between the two communities. I'm not sure exactly what I'm suggesting we do about this. It would be nice if we could provide binaries built with VC9, or if we could recommend on the download site that people get binaries from ApacheLounge. I don't know if either of these is really an option. How would folks feel about our download site encouraging folks to use ApacheLounge's version of 2.2? I suspect that there'd be some resistance to this, based on our previous interactions with them. I have a foot in the documentation team of both projects, so I tend to hear both sides of the conversation at least from that perspective. I'd like for us to be more proactive about strengthening the community bond between us and what is probably the most important third-party Apache httpd module. There seems to be a pretty strong "they don't ever listen to us" attitude on both sides, and I'm not sure that it's really warranted. -- Rich Bowen rbo...@rcbowen.com
Re: Some love for balancer manager?
On Dec 22, 2010, at 9:27 AM, Daniel Ruggeri wrote: During Rich's ApacheCon presentation he mentioned that some much needed love for the balancer manager was on its way... is anyone working on this currently? I'm not seeing anything in the released alphas and would be happy to be a guinea pig to do some testing/give thoughts. I was quoting the presentation immediately before mine, and not speaking on my own knowledge. But what I understood was that there was the added ability to add/remove balancer members through the manager. I made a mental note to check up on this when i got home, and promptly forgot. -- Rich Bowen rbo...@rcbowen.com
Re: Relative vs Absolute Options (PR 33078)
On Dec 24, 2010, at 10:56 AM, Igor Galić wrote: Hi folks, I'd like to apply the attached patch to trunk. It's based on the one in PR#33078, disallowing the mixing of relative and absolute options (for combinations which really don't make any sense). This "feature" has been proven to be very costly: in support hours - which is why I'd like to get rid of it. Opinions? +1, I think. Remember that "All" does not include MultiViews, so it's feasible that you'd want to have Options Multiviews followed by Options +All. Perhaps someone can remind me why All doesn't include Multiviews? -- Rich Bowen rbo...@rcbowen.com
Re: ditch NameVirtualHost directive?
On Dec 8, 2010, at 12:07 PM, Eric Covener wrote: ... and assume overlaps are intentional opt-in to name-based vhosts? The selection algorithm would not change, meaning you'd still only be selecting from the best ip-based match. We'd lose the warning about overlapping vhosts, and maybe incur some overhead on mapping a vhost that was unintentionally showing up multiple times. Just kicking the idea around since NVH seems to be tough for users to grok. +1 to the concept. Virtual hosts are (based on user questions) too hard to understand, and I think we could improve that situation by making the configuration smarter. -- Rich Bowen rbo...@rcbowen.com
Re: Developer documentation
On Dec 7, 2010, at 6:02 AM, Igor Galić wrote: 05:54 < gmcdonald> jMCg: http://ci.apache.org/projects/httpd/trunk/doxygen/ 06:21 < infrabot> Gavin Closed: (INFRA-3252) Please add a nightly doxygen build for httpd trunk Now all we need to do is link to it. If it turns out we like it even more than just that, we should have it published directly to site. Done r1042988 | rbowen | 2010-12-07 06:57:36 -0500 (Tue, 07 Dec 2010) | 2 lines Changed paths: M /httpd/httpd/trunk/docs/manual/developer/index.html.en M /httpd/httpd/trunk/docs/manual/developer/index.xml Use the developer docs on ASF hardware, instead of rcbowen.com Thanks, Gav. -- Rich Bowen rbo...@rcbowen.com
Re: Developer documentation
On Dec 1, 2010, at 11:24 AM, Igor Galić wrote: The first topic discusses is ``Apache *1.3* API Notes'' http://modules.apache.org/doc/API.html http://httpd.apache.org/docs/trunk/developer/API.html http://httpd.apache.org/dev/API.html All reference the same document, and from what Rich told me that's *pre* 1.3... Yep. Shambhala is what became 1.0 -- Rich Bowen rbo...@rcbowen.com
Re: Developer documentation
On Nov 28, 2010, at 9:38 AM, Stefan Fritsch wrote: On Sun, 28 Nov 2010, Igor Galić wrote: There's a PR, over three years old now: https://issues.apache.org/bugzilla/show_bug.cgi?id=42000 complaining about the accuracy of the debugging documentation. Taking a look at it, I found that s/POOL_DEBUG/APR_POOL_DEBUG/ is an easy fix, but as far as the rest goes, this is near impossible for your run-of-the-mill docs@ contributor. Looking further, I found a number of disharmonics. The only place ALLOC_DEBUG is referenced is in test/ Most of the stuff in there hasn't been touched since a license header update 2006. What is test/? http://httpd.apache.org/docs/*trunk*/developer/ Welcomes us to ``Developer Documentation for Apache *2.0*'' The first topic discusses is ``Apache *1.3* API Notes'' I particularly like http://httpd.apache.org/dev/API.html which is the Shambhala API. Nice from a historical perspective, but makes us look like abandonware. Rich has linked the autogenerated doxygen reference on his server as external resource. That's cool - but would probably make a better picture if it was hosted on httpd.a.o ;) It would especially make a better picture if there was a cron job that kept the docs up-to-date. Rich's page is somewhat out of date by now. Yes. It is. I didn't want to dump it wholesale into the docs before I figured out how to auto-update it. I could use some help on this. I think, unfortunately, that this falls squarely on the docs team to JFDI, although, granted, we need quite a bit of help for the twiddly bits. I would rather have nothing, or just the auto-gen docs, than have all this old and contradictory stuff as our only API documentation. Additionally, there's a lot of outdated and Just Plain Wrong stuff on http://modules.apache.org/reference.php which is hosted elsewhere. That (modules.apache.org in general) has come up again and again, but nobody really has the time/passion to do much about it. -- Rich Bowen rbo...@rcbowen.com
Re: svn commit: r1041011 - in /httpd/httpd/trunk/docs: conf/httpd.conf.in manual/misc/security_tips.xml manual/misc/security_tips.xml.fr manual/misc/security_tips.xml.ko manual/misc/security_tips.xml.
Modified: httpd/httpd/trunk/docs/conf/httpd.conf.in URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/httpd.conf.in?rev=1041011&r1=1041010&r2=1041011&view=diff = = = = = = = = == --- httpd/httpd/trunk/docs/conf/httpd.conf.in (original) +++ httpd/httpd/trunk/docs/conf/httpd.conf.in Wed Dec 1 13:52:56 2010 @@ -177,7 +177,7 @@ DocumentRoot "@exp_htdocsdir@" # The following lines prevent .htaccess and .htpasswd files from being # viewed by Web clients. # - + Require all denied That's not right. Either use Files or Filesmatch. If you want to use Files ".ht*" then you need to . You want to fix this, or should I get it? -- Rich Bowen rbo...@rcbowen.com
Re: Options All
On Nov 18, 2010, at 11:52 AM, William A. Rowe Jr. wrote: On 11/18/2010 7:43 AM, Nick Kew wrote: On Thu, 18 Nov 2010 11:46:06 + (UTC) Igor Galić wrote: Would it be sensible to change the default here as well? This is the kind of question that should better be discussed with downstream users, especially packagers, than with developers. If in doubt, don't change without at least a consensus among the distros. There's enough end-user confusion about defaults that differ from what they've read. Let's not add to it ourselves! Packagers don't follow our structure, and rarely follow our recommendations. I wouldn't worry about them, ask on users@ or docs@ for a user perspective. The end goal to changing default values should always be (IMO) what happens when you start httpd with no config file. I don't realistically think that we'll get there - there's too many things that have to be set - but hypothetically, that should be what we're working towards when we make changes like this. So, +1 to changing this, as it give us something that is safe to have set server-wide. -- Rich Bowen rbo...@rcbowen.com
Re: SetVirtualDocumentRoot
On Nov 10, 2010, at 11:26 AM, Plüm, Rüdiger, VF-Group wrote: -Original Message- From: Rich Bowen To: dev@httpd.apache.org Subject: SetVirtualDocumentRoot I was reading bug reports this morning, and wondered if someone could take a look at the patch offered here: https://issues.apache.org/bugzilla/show_bug.cgi?id=26052#c19 The patch doesn't look appealing to me. Having a module changing the core config on the fly always looks nasty to me, even more so if it stores data in the core config structure that is allocated from a request pool. IMHO this is waiting for all nasty things to happen, SEGFAULT at best. Ok. Fair enough. How about something that set the ENV var for just the current request? The frequency with which this gets asked seems to make it worthwhile doing something, even if this patch isn't the right thing to do. -- Rich Bowen rbo...@rcbowen.com
SetVirtualDocumentRoot
I was reading bug reports this morning, and wondered if someone could take a look at the patch offered here: https://issues.apache.org/bugzilla/show_bug.cgi?id=26052#c19 It adds a SetVirtualDocumentRoot configuration directive to mod_vhost_alias, making numerous third-party applications behave sanely when run under mod_vhost_alias. I've read the various justifications why we don't do this, and quite frankly I don't understand them. Is there a legitimate reason that setting DOCUMENT_ROOT on a per-dynamic-vhost basis is any different/ worse than setting it on a per-regular-vhost basis? I don't understand the distinction, other than "we've never done it that way." Thanks. -- Rich Bowen rbo...@rcbowen.com
Re: [RFC] Error directive to generate custom error messages from httpd.conf
On Nov 7, 2010, at 7:35 PM, Jeff Trawick wrote: Error mod_foo requires mod_include! Use the LoadModule directive to load mod_include. $ ./httpd -t Syntax error on line 486 of /home/trawick/inst/23/conf/httpd.conf: mod_foo requires mod_include! Use the LoadModule directive to load mod_include. Swet. +1 Better error messages are always a plus. -- Rich Bowen rbo...@rcbowen.com
Re: Patch for mod_ssl
Thanks.
I've applied the patch, based on the approval received so far.
I like error messages that are informative and tell you how to fix the
problem.
On Nov 4, 2010, at 2:32 PM, Jim Jagielski wrote:
+1
On Nov 4, 2010, at 12:26 PM, Rich Bowen wrote:
I'd like to make the following change to mod_ssl in 2.2. It's
actually a documentation change, in the sense that it changes an
error message, but I wanted to be sure that there's no strong
objection to the change before I make it. This attempts to avoid
the confusion that happens when you get an error message that
doesn't actually tell you anything useful.
Note: I've also made this change in trunk.
Index: ssl_engine_init.c
===
--- ssl_engine_init.c (revision 1029506)
+++ ssl_engine_init.c (working copy)
@@ -403,7 +403,7 @@
{
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
"Illegal attempt to re-initialise SSL for server "
-"(theoretically shouldn't happen!)");
+"(SSLEngine On should go in the VirtualHost, not
in global scope.)");
ssl_die();
}
}
--
Rich Bowen
rbo...@rcbowen.com
--
Rich Bowen
rbo...@rcbowen.com
Patch for mod_ssl
I'd like to make the following change to mod_ssl in 2.2. It's actually
a documentation change, in the sense that it changes an error message,
but I wanted to be sure that there's no strong objection to the change
before I make it. This attempts to avoid the confusion that happens
when you get an error message that doesn't actually tell you anything
useful.
Note: I've also made this change in trunk.
Index: ssl_engine_init.c
===
--- ssl_engine_init.c (revision 1029506)
+++ ssl_engine_init.c (working copy)
@@ -403,7 +403,7 @@
{
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
"Illegal attempt to re-initialise SSL for server "
-"(theoretically shouldn't happen!)");
+"(SSLEngine On should go in the VirtualHost, not in
global scope.)");
ssl_die();
}
}
--
Rich Bowen
rbo...@rcbowen.com
Oops. Sorry. (Re: flood to bugs@, docs@)
Um. Sorry guys. I just assigned the open docs bugs to the d...@httpd.a.o account, and triggered that flood of bugzilla messages. I'm very sorry. You can scold me at ApacheCon on Monday. -- Rich Bowen rbo...@rcbowen.com http://drbacchus.com/
Re: Apachecon hackathon?
On Oct 26, 2010, at 11:40 AM, William A. Rowe Jr. wrote: On 10/26/2010 7:21 AM, Dan Poirier wrote: To participate in the hackathon, do we just show up Monday morning? (If so, when and where?) Or is there a signup or something? That's about it... just ask around which table the httpd folks are hanging around (some of them will likely break away to powwow about infrastructure things at yet another table, where some discussions will be root@ only, as you can well imagine.) Just pull up a chair to the httpd table. There's a number of documentation-specific tasks that we're going to try to take care of during the week, too. These will be (assuming I get to it soon) listed in the STATUS file under the docs dir, although certainly any docs improvements are welcome. -- Rich Bowen rbo...@rcbowen.com http://drbacchus.com/
Re: Time for a new iconset?
On Oct 19, 2010, at 5:52 PM, Javier Llorente wrote: On Martes, 19 de Octubre de 2010 01:39:05 Igor Galić escribió: - "Javier Llorente" wrote: Hello list-mates, I think that the current icons used in directory listing look a bit old. Perhaps it's time to make a call for help creating a new iconset? I am not an icon designer but I'm willing to help. The icons I'm thinking of are the following: Hi Javier! I remember the last time you offered us your ideas, there was trouble with licencing, is that still the case? It wouldn't be the case since it's about creating a new iconset, not basing it on something else. That would be awesome. Thanks. -- Rich Bowen rbo...@rcbowen.com http://drbacchus.com/
Re: [Vote] Retire 2.0.x branch?
On Oct 18, 2010, at 11:54 AM, William A. Rowe Jr. wrote: With a release on the way with a host of good bits, almost 2 years after its previous release, it seems time that the group might consider the following options... [ ] Leave 2.0.x open to maintenance [ ] Leave 2.0.x open to security/critical bug fixes only [X] Retire 2.0.x (but accumulate patches/apply_to_2.0.64) Yes please. Also, useful (if anecdotal) data point: While 1.3 support requests took forever to dwindle (almost, but not quite, gone now) 2.0 requests went away very rapidly with the release of 2.2. It's as though everyone considered the 1.3 -> 2.x jump a major step, but the 2.0 -> 2.2 jump pretty minor. I hardly ever encounter 2.0 users -- Rich Bowen rbo...@rcbowen.com http://drbacchus.com/
Re: svn commit: r1004243 - /httpd/httpd/branches/1.3.x/htdocs/manual/mod/core.html.en
On Oct 4, 2010, at 10:42 AM, Nick Kew wrote: On Mon, 04 Oct 2010 14:08:50 - rbo...@apache.org wrote: Modified: httpd/httpd/branches/1.3.x/htdocs/manual/mod/core.html.en Um, shouldn't that be the XML source? 1.3 docs don't have xml sources. It's all just HTML. + Uppercase!! Oy. Ok, fixed. :) -- Rich Bowen rbo...@rcbowen.com
Re: htaccess support
On Sep 27, 2010, at 11:50 AM, Rich Bowen wrote: The testing I did was on a site with no .htaccess files. I did: AllowOverride All And, yes, I acknowledge that this is a stupid thing to do, and specifically discouraged in the documentation. It was to prove a point. :) -- Rich Bowen rbo...@rcbowen.com
Re: htaccess support
The testing I did was on a site with no .htaccess files. I did: AllowOverride All and that, all by itself (with no .htaccess files) dropped performance by about 25 - 50%, depending on how deep in the directory tree I went. I don't think I've ever done a 1.3/2.x comparison. On Sep 27, 2010, at 11:01 AM, Stefan Fritsch wrote: Was that benchmarking in 1.3 time? I have had the experience that the parsing of .htaccess is *a lot* more heavy-weight in 2.x than it used to be in 1.3. -- Rich Bowen rbo...@rcbowen.com
Re: htaccess support
On Sep 27, 2010, at 7:44 AM, Igor Galić wrote: Hi folks, I remotely remember that we briefly touched this topic on IRC, but I'd really like to bring this to the lists attention: .htaccess is one of the features that have guaranteed httpd's success in the past, and at the same time it's the single biggest clutch imaginable. It's a support nightmare, exploit vector and a performance bottleneck. Most competing products don't have such a thing either, and if needed, solve it via scripting: http://diaryproducts.net/about/web_servers/lighttpd/htaccess_lighttpd (first hit in google, I'm sure you can do better) I'd like to discuss the possibility to either disable the use of .htaccess at compile time, or alternatively concentrate it into a module. With mod_lua in place, people who chose to, could use yet a different way for per-dir configs, I suppose... As much as we dislike .htaccess files, they certainly seem to be a necessary evil. You *can* disable them (although not at compile time), but this is simply not an option for many folks. Educating them when it's better to use the main config than .htaccess files is the job of documentation, and we've done a somewhat poor job of that. Perhaps that can be improved. The largest problem here is the *HUGE* number of third-party sites peddling bad advice, and I honestly have no idea how to address that problem. It's been frequently suggested that .htaccess files could be improved via some kind of "cache and only reload if the timestamp has changed" mechanism, but in my benchmarking, simply stat'ing a .htaccess file (even in cases when there's no file there to begin with) accounts for an awful lot of the performance hit of "AllowOverride All", so I don't know whether this would really be a solution. For the most part, folks who need to use .htaccess files are not in a position to really do much in the way of performance tuning, and vice versa. -- Rich Bowen rbo...@rcbowen.com
Re: ScriptLog
On Sep 25, 2010, at 8:08 PM, Stefan Fritsch wrote: On Sunday 26 September 2010, Rich Bowen wrote: Another question on this thread - is ScriptLog also going away? It hasn't been on my radar so far. Should it? pros: - per dir config instead of per vhost - possibly finer control with different trace levels cons: - data would use more space in error log because of the log prefix on every line - ScriptLogLength would go away, too +1 It would certainly make it easier to document. ;-) It would be handy for every module to have the same logging methods, rather than having an "except for mod_cgi" in the docs. However, I must admit that I have never (or, at least, not in the last decade) used ScriptLog myself much, so perhaps someone who's actually used it extensively should weigh in on this. -- Rich Bowen rbo...@rcbowen.com
Re: RewriteLog and other per-module logging
Another question on this thread - is ScriptLog also going away? -- Rich Bowen rbo...@rcbowen.com
Re: RewriteLog and other per-module logging
On Sep 21, 2010, at 3:01 PM, Stefan Fritsch wrote: I considered that in the beginning but then thought that its usefulness would not outweigh the added complexity. After all, the result is only one grep away: fgrep '[rewrite:' error_log or even tail -f error_log|fgrep '[rewrite:' > rewrite_log Do you really think that we need this in httpd itself? Hmm. You're probably right. This is probably something to "fix in documentation" rather than adding the extra complexity. :) -- Rich Bowen rbo...@rcbowen.com
RewriteLog and other per-module logging
So, I expect it's my own fault for not paying attention to this list as closely as I once did, but ... Losing the ability to have a separate mod_rewrite log file will make troubleshooting rewrite stuff so very much more difficult. Is there anything planned for the ErrorLog directive that would let me do something like: ErrorLog rewrite:/file/path so that different modules could have their own log files, in addition to their own LogLevel settings? I certainly see the value of having one combined logging mechanism, but having all those messages flowing into a single log file is going to increase troubleshooting complexity, and I suspect that folks are going to be rather annoyed at the loss of the RewriteLog directive without something comparable to replace it. -- Rich Bowen rbo...@rcbowen.com
Re: Stop accepting PRs for 1.3?
On Apr 29, 2010, at 11:13 PM, Sander Temme wrote: Crowd, Since we have released our last release, how about we close the Apache httpd-1.3 product in Bugzilla for entering new bugs? Say the word and I'll click the clicky in the Bugzilla admin. +1 This would be an important step in driving migration to more modern versions. -- Rich Bowen rbo...@rcbowen.com
Re: OpenBSD & the Apache license problem. Why?
On Apr 28, 2010, at 8:51 AM, Eric Covener wrote: Oh, by the way, what was your answer for: "There is a number of serious security problems in apache that we have fixed, and that have been offered them back, and they refused." @ http://marc.info/?l=openbsd-misc&m=108655793112947&w=2 Why would there be an 'answer' to a) a statement and b) something that was posted on somebody elses mailing list? May i know what did you refuse and why did you refuse? You'd have to refer to a specific bug report, patch, mailing list reference, or at least a specific issue for anyone to comment intelligently -- especially if this 6+ years ago. This is probably more on-topic at the users discussion list unless there's an actual question about the development of Apache HTTP Server. Having seen this referenced several times in the last few weeks (was there a news story that resurrected this?) I've wondered about this claim, too. Can someone who remembers this incident please speak up and set the record straight about what actually happened? It seems improbable to me that there's just one side of this story, and that nobody remembers it from our perspective. What was refused, and why? Or is that not actually how it happened? -- Rich Bowen rbo...@rcbowen.com
Re: Oxygen icons for Apache
On Apr 21, 2010, at 3:13 PM, Javier Llorente wrote: Oops I forgot. It's under the LGPL. I am not sure if it's compatible with Apache's licensing policy. Well, that's not happening then, but thanks for your enthusiasm :) I have used some LGPL'ed icons. However, from my understanding of the LGPL, I could change the license of my collection to make it compatible; If it's your work, you're welcome to relicense it under whatever license you like, including ASL2. -- Rich Bowen rbo...@rcbowen.com
Re: Oxygen icons for Apache
On Apr 21, 2010, at 11:44 AM, Javier Llorente wrote: Apache's current icons are a bit out-of-date, so I've created a collection of icons for Apache; it has oxygen+crystal+custom icons, a config file and a README. Perhaps it could be included in Apache, so that sys admins have another option :-) You can see it live at http://www.javierllorente.com/tmp/ +1 Am I correct in understanding that you're donating these to the Apache HTTP Server project, or that they're under a license that permits us to redistribute them? -- Rich Bowen rbo...@rcbowen.com
RFP: HTTPD Training Classes for ApacheCon Atlanta
I'm coming to you first because you know (and in some cases, you are) the very best trainers and most knowledgeable people in the area of your project. We need your help gathering the best training sessions for ApacheCon North America 2010 in Atlanta. Here's what we need: Training sessions, either half day (3 hours), full day (6 hours), or 2- day (12 hours). We need a description of the training and the speaker, put into the wiki, here:http://wiki.apache.org/httpd/ApacheCon2010AtlantaTraining Here's what you get: If your training class is selected, you get: * Nights in the hotel: Half-day training: 3 nights for one trainer Full-day training: 4 nights for one trainer Two-Day training: 5 nights for one trainer * Travel allowance up to $850.00 USD – will be paid within 30 day of conference completion and the receipt of travel costs. * Compensation If your class sells the minimum number of seats (11), you'll get a cut of the profits: * Two-Day and One-Day trainers will receive $1,000.00 * Half-Day Trainers will receive $600.00 * 25% of any registration after 15 people (i.e attendee 16 will be split 25% and 75% with the conference) Please share these details with your developer lists, and with any individuals who you know to be good trainers in your particular topic. Please let me know any questions you have. -- Rich Bowen, for the ApacheCon Conference Committee rbo...@apache.org
Re: Documentation writing at the Apache Retreat in Ireland
On Mar 17, 2010, at 3:06 PM, Andrew Ford wrote: I have signed up for the Apache Retreat in Wicklow (and my employer is providing me with time off!). I had said that I would work on the Apache HTTPD documentation once I had finished writing "The Apache2 Pocket Reference", but work and real life intervened. I would be interested to know whether anyone else is planning on working on documentation at the retreat, and if there are areas of the documentation that it was felt could particularly do with some intensive attention? I wish I could be there to help you out with this. There's a STATUS file in the docs/ directory, which I have been updating lately. I think two major areas are security and performance, which are both rather poorly covered. But there's also a lot of other things that could consume a weekend. --Rich
Re: svn commit: r923712 - in /httpd/httpd/trunk/docs/manual: ./ mod/
On Mar 16, 2010, at 1:24 PM, Roy T. Fielding wrote: On Mar 16, 2010, at 5:48 AM, rbo...@apache.org wrote: Author: rbowen Date: Tue Mar 16 12:48:31 2010 New Revision: 923712 URL: http://svn.apache.org/viewvc?rev=923712&view=rev Log: In as much as we can be said to have consensus on anything at all, we appear to have consensus that we will refer to the product (in the documentation) as Apache HTTPD, or HTTPD for short, and to the server binary executable as httpd. Here's a few changes to that effect. WTF? -1 Apologies. The goal is to stop using 'Apache', by itself, to refer to the server, and to replace it with something that distinguishes the foundation from this particular project. This was requested by wrowe, from a different angle, by Sally and the PRC. I'll cease in this endeavor until there's some kind of agreement as to what it should be replaced with. It appears that we're a ways away from that. --Rich
Re: Deprecate the RewriteLog directive
On Mar 12, 2010, at 1:44 PM, Graham Leggett wrote: Hi all, I am currently having a torrid time trying to debug a mod_rewrite problem, and my efforts have been thwarted by: - mod_rewrite for some reason has it's own logging subsystem, instead of using the standard httpd logging. - mod_rewrite doesn't seem to support the concept of directive inheritance, so the moment you specify "RewriteEngine on", any inherited config - including your RewriteLog directive - gets blown out the window. What I propose is that we deprecate the RewriteLog directive, and replace all logging functionality in mod_rewrite with standard httpd logging. Would v2.4 be an acceptable time to introduce something like this? That would be delightful. Many things in mod_rewrite presumably seemed like a good idea at the time, but with ten years perspective make me wonder what Ralf was thinking.
Re: autogen API docs
On Mar 11, 2010, at 3:44 PM, Jeff Trawick wrote: On Thu, Mar 11, 2010 at 12:33 PM, Rich Bowen wrote: On Mar 11, 2010, at 10:48 AM, Jeff Trawick wrote: On Thu, Mar 11, 2010 at 10:46 AM, Rich Bowen wrote: Can someone point me to information on how to autogen API docs from the source? The link on the website points to something purportedly by Ian Holmsman, but the link is dead. Does "make dox" work for you? Awesome. That works for trunk. What about 2.2 and 2.0? Is this a new development, or am I just missing something?\ The same make target is in 2.2 and 2.0 as well. (I don't have much info on it; IIRC, I've only used the APR equivalent myself.) My problem appears to lie elsewhere - in particular, I can't get buildconf to run, due to the bad advice that it's giving me about where to get apr-util. I need to come back to this later when I have more time to tinker with it.
Re: autogen API docs
On Mar 11, 2010, at 10:48 AM, Jeff Trawick wrote: On Thu, Mar 11, 2010 at 10:46 AM, Rich Bowen wrote: Can someone point me to information on how to autogen API docs from the source? The link on the website points to something purportedly by Ian Holmsman, but the link is dead. Does "make dox" work for you? Awesome. That works for trunk. What about 2.2 and 2.0? Is this a new development, or am I just missing something? --Rich
autogen API docs
Can someone point me to information on how to autogen API docs from the source? The link on the website points to something purportedly by Ian Holmsman, but the link is dead. Thanks. --Rich
Re: svn commit: r903052 - /httpd/httpd/trunk/modules/generators/mod_autoindex.c
On Jan 26, 2010, at 02:05 , Ruediger Pluem wrote: Please do not use C++ style comments as they fail on ANSI compilers. Thank you. Fixed. -- Rich Bowen rbo...@rcbowen.com
Re: [VOTE] Formal deprecation of 1.3.x branch
On Jan 6, 2010, at 06:22 , Colm MacCárthaigh wrote: If one of the goals here is to reduce the support nuisance and help folk out, should we also ask the Apache PR team for help? I'm sure they'd be willing to help publicise the change "After 15 years of community support ... mumble mumble ... marking version 1 of Apache as end of life with final release ...mumble mumble ... 10 years of successful Apache 2 ... mumble mumble .. please use 2.2.x " . Yes please. At least give PRC a chance to say "yes, what you've written is just fine", on the off chance that they'll say it needs something else. -- Rich Bowen rbo...@rcbowen.com
Re: [VOTE] Formal deprecation of 1.3.x branch
On Jan 5, 2010, at 15:31 , Jorge Schrauwen wrote: +1 (non-binding) There are still to many questions about the 1.3 branch on the support channels IMHO One hopes that a formal EOL statement will be the encouragement that most of these folks need to move into the new century. -- Rich Bowen rbo...@rcbowen.com
Re: [VOTE] Formal deprecation of 1.3.x branch
Speaking from the community that provides end-user support for these products, a big +1 on that proposal. On Jan 4, 2010, at 16:57 , Colm MacCárthaigh wrote: Observers of the commits list may have noticed some small cleanups to the 1.3.x branch earlier today. There are currently a number of several years-old backport/patch proposals in there too, including two marked as release show-stoppers (neither actually stopped the show, when last we had a release). I've reviewed and tested the relatively low-hanging fruit, and cleaned up the backport proposals to be functional patches. If you really really think any of those patches are important, now is a good time to review/test/vote! Because ... stealing an idea from wrowe@ ... how about we formally deprecate the 1.3.x branch? Make one more release, but attach a notice to the effect that it will be the final release, and that in future we'll be distributing security updates by other means :-) Patch; Index: README === --- README (revision 895672) +++ README (working copy) @@ -14,9 +14,16 @@ The Latest Version -- - Details of the latest version can be found on the Apache HTTP - server project page under http://httpd.apache.org/. + As of January 2010, support for version 1.3 of Apache has been + formally deprecated. Updates will be available as patches, from + http://www.apache.org/dist/httpd/patches/ + Users are encouraged to upgrade to version 2 of Apache httpd, + and information on upgrading is available at; + + http://httpd.apache.org/docs/2.0/upgrading.html + http://httpd.apache.org/docs/2.2/upgrading.html + Documentation - Index: src/CHANGES === --- src/CHANGES (revision 895795) +++ src/CHANGES (working copy) @@ -1,6 +1,22 @@ Changes with Apache 1.3.42 + *) INFORMATIONAL: Please note that this release is considered + the final release of the Apache 1.3.x branch. Future + updates will be distributed as patches, via + http://www.apache.org/dist/httpd/patches/ + + Apache 1.3.x users who wish to avail of security releases + are advised to use Apache 2 or higher. Please see; + + http://httpd.apache.org/docs/2.0/upgrading.html + http://httpd.apache.org/docs/2.2/upgrading.html + + for information on upgrading. On behalf of the Apache + httpd group; thank you to everyone who helped make + Apache 1.3.x the most successful, and most used, + webserver software on the planet. + Changes with Apache 1.3.41 *) SECURITY: CVE-2007-6388 (cve.mitre.org) -- Colm -- Rich Bowen rbo...@rcbowen.com
Re: svn commit: r894298 - in /httpd/httpd/trunk: docs/manual/mod/mod_autoindex.html.en docs/manual/mod/mod_autoindex.xml modules/generators/mod_autoindex.c
On Dec 29, 2009, at 12:20 , Nick Kew wrote: On 29 Dec 2009, at 02:18, rbo...@apache.org wrote: Author: rbowen Date: Tue Dec 29 02:18:55 2009 New Revision: 894298 URL: http://svn.apache.org/viewvc?rev=894298&view=rev Log: Adds alternating CSS classes to table rows for trendy striped table support. FWIW, there's an open PR in bugzilla about adding something slightly more extensive to mod_autoindex, and at first glance it makes sense. Furthermore, it's got a patch! Maybe you could review it while your focus is on mod_autoindex: see if there's something worthwhile that doesn't duplicate your patches, or just close it if it's overtaken by events. https://issues.apache.org/bugzilla/show_bug.cgi?id=34014 Oooh. Nice. I'll look at it this evening. I was also fiddling with your suggestion of putting stuff in a template, but I haven't gotten very far with that. -- Rich Bowen rbo...@rcbowen.com
Re: mod_rewrite patch
On Dec 28, 2009, at 05:51 , Vincent Bray wrote: 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 ;-) That's a good point. I'd prefer to see the query string preserved in that case. So, QSD only has an effect if the rule contains no query string. This slightly revised patch has the effect described above. That is, the original QS is discarded, but any QS on the target is added on - which would have been the effect if you hadn't used QSD at all. Note also that if you use QSA and QSD at the same time, QSD wins, and the replacement query string is used by itself, rather than appended to the original query string. Here again, it's far from clear what someone would expect, when using both flags. rewrite.diff Description: Binary data -- Rich Bowen rbo...@rcbowen.com
Re: mod_rewrite patch
On Dec 28, 2009, at 05:45 , André Malo wrote: 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 ;-) On the one hand, if you REPLACE the query string like this, then the original query string is removed already, without using the QSD flag. It's not at all clear what they had in mind when using that flag with a replacement query string. What were they trying to accomplish? The solution is, "don't do that". On the other hand, in my testing, that rule did in fact sort of work, with the new query string being stuck on, but escaped, which isn't what I expected. That is, I ended up at bar%3fx=y I'll have to look at this a little closer ... -- Rich Bowen rbo...@rcbowen.com
mod_rewrite patch
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. I'm also aware that a patch of this kind was submitted a couple years back and ignored, but I wasn't able to find it in the archives. rewrite.diff Description: Binary data -- Rich Bowen rbo...@rcbowen.com
Re: Autoindex patch
On Dec 27, 2009, at 15:38 , Nick Kew wrote:
Alternating classes support
trendy striped tables (for whatever that's worth),
...
So, since my intent was, in fact, just to add "trendy striped tables",
here it is again:
Index: mod_autoindex.c
===
--- mod_autoindex.c (revision 894107)
+++ mod_autoindex.c (working copy)
@@ -1482,6 +1482,7 @@
char direction, const char *colargs)
{
int x;
+int row_count;
apr_size_t rv;
char *name = r->uri;
char *tp;
@@ -1658,7 +1659,23 @@
}
if (autoindex_opts & TABLE_INDEXING) {
-ap_rputs("", r);
+ap_rputs("style_sheet != NULL) {
+ap_rputs(" class=\"", r);
+if ( row_count % 2 == 0 ) {
+ap_rputs("ai_tr_even", r);
+}
+else {
+ap_rputs("ai_tr_odd", r);
+}
+ap_rputs("\"", r);
+row_count++;
+}
+
+ap_rputs(">", r);
+
if (!(autoindex_opts & SUPPRESS_ICON)) {
ap_rputs("", r);
if (autoindex_opts & ICONS_ARE_LINKS) {
--
Rich Bowen
rbo...@rcbowen.com
Re: Autoindex patch
On Dec 27, 2009, at 15:38 , Nick Kew wrote: Any classes you attach are by definition arbitrary. A class for adds absolutely nothing. Neither does unless you use different classes for different instances of it. Alternating classes support trendy striped tables (for whatever that's worth), but IMHO if we're going down that road, we'd be better taking the HTML out of the code altogether and turning it into a template the webmaster can hack at leisure. I started with just the alternating tr classes, but then thought, well, someone is going to complain that I didn't go far enough, and so added the other stuff, even though I, personally, only have use for the alternating tr classes. I suppose that'll teach me to go father than my own itch. -- Rich Bowen rbo...@rcbowen.com
Autoindex patch
A couple years back, the IndexStyleSheet directive was introduced, but was of limited usefulness for some of the stuff folks wanted to use it for, simply because the HTML didn't contain any CSS classes. The attached patch is a simple proof-of concept, introducing the CSS classes ai_table, ai_th, ai_tr, ai_tr_odd and ai_tr_even that you can then style in an IndexStyleSheet. This allows you to do things such as alternating rows in the directory listing. Yes, technically I have commit rights, and I'm aware that trunk is CTR, but since I've never actually committed outside of the docs, I wanted to run this by dev@ for feedback. Yes, there will be docs to go along with it if/when it is committed. autoindex.diff Description: Binary data -- Rich Bowen rbo...@rcbowen.com
Re: Obsolete modules in 2.3
On Nov 17, 2009, at 21:49 , William A. Rowe Jr. wrote: Roy T. Fielding wrote: I personally find it useful to continue having support for features that were once used in the past, specifically to test things that once worked to see if they still work with the current version of Apache. Therefore, I do not consider these modules to be obsolete. Unless they are somehow broken right now or preventing us from doing some big change to the architecture, then -1 to removing them. They should not be compiled by default, of course. I'd be +1 for moving both from modules=most to modules=all. They certainly don't eat a lot of space and are historically if not currently interesting. Ok. I defer and withdraw my request. Having them not included in modules=most would be great. Thanks. -- Rich Bowen rbo...@rcbowen.com
Re: Zero Config
On Nov 13, 2009, at 07:20 , Mark Watts wrote: +1, and can we _please_ default RewriteEngine to "on". +1 Yes, that would be very nice. If I have a RewriteRule, don'tcha think I want it to run? -- Rich Bowen rbo...@rcbowen.com
Zero Config
On Nov 13, 2009, at 06:39 , Igor Galić wrote: It's been a long time now, but I still remember Rich asking for a Apache httpd starting *without* a config. I'm not sure this is easily doable, but I'm pretty confident that we can slim down the basic config (httpd.conf) to a very minimalistic level and put all the fluff in extra Of course it's doable. Easily? I don't know. But certainly doable. You define and document default values for everything, and then config directives are only ever needed when things differ from the default. Lots of products do this. The default for LoadModule could be that you load all modules in HTTPD_ROOT/modules unless there are LoadModule directives specifying otherwise. We could (and should) protect by default, and allow access to HTTPD_ROOT/htdocs by default. And so on. Much of the stuff that's in those configs you referenced can already be omitted and fall back to default values. -- Rich Bowen rbo...@rcbowen.com
