I was recently looking for the original CGI specification (strangely, one of the URLs I memorized years ago and never forgot – hoohoo.ncsa.uiuc.edi/CGI) and found a mirror of it. I decided to obtain my own copy of it so that I can have a more permanent archive of my own for historical purposes.
Be aware that because it is a mirror or a long-dead server, some of the links might not work quite as expected.
Related documentation
The Allow, Deny and Order directives have long been ones that people have found confusing and counterintuitive. And although they could be combined in various ways, using the Satisfy directive, they were still rather limiting. Complex combinations of restrictions were often very difficult.
Among the new features on 2.4 are new Require directives and syntaxes that allow very complex combinations of requirements.
mod_access_compat retains the old Allow, Deny, Order, Satisfy syntax, to ease the transition off of it. However, these directives have been removed from all example configurations, and you’re encouraged to stop using them.
The Require works much like it always has, although new options are added to it to replace the Allow/Deny syntax:
Require all grantedRequire all deniedRequire env env-var [env-var]
...Require method http-method [http-method]
...Require expr expression The Require expr syntax uses the new expression engine, and so allows for very complex requirements.
Additionally, various other modules can augment the Require syntax with other requirements. For example, mod_authz_host provides access control by IP address:
Require ip 192.168
Other than the Require expr syntax, much of the above is as before, just stated more clearly. But the other directives I want to talk about here give you ways to combine the requirements that were not possible at all before.
The RequireAll directive allows you to combine several requirements and enforce all of them. RequireAny says that any one of the requirements is similar. And RequireNone says that none of the requirements must be true. What’s really powerful about these is that they are containers, and so can be nested within one another to create arbitrarily complex scenarios.
First, a few simple examples:
In the first example, we require that a client be either on our local network, or that they be authenticated with a username and password. Either one is sufficient. That is, if they’re on our local network, they won’t be asked for a password.
<RequireAny> Require ip 10.2 Require valid-user </RequireAny>
Alternately, we could require both – that they be on our local network and that they provode a password:
<RequireAll> Require ip 10.2 Require valid-user </RequireAll>
Finally, we could require that we won’t permit any access from someone who’s on our local network, or who is logged in.
<RequireNone> Require ip 10.2 Require valid-user </RequireNone>
This gets really interesting when you want to enforce several different kinds of access control in different ways:
<RequireAll> <RequireAny> Require user superadmin <RequireAll> Require group admins Require ldap-group cn=Administrators,o=Airius <RequireAny> Require group sales Require ldap-attribute dept="sales" </RequireAny> </RequireAll> </RequireAny> <RequireNone> Require group temps Require ldap-group cn=Temporary Employees,o=Airius </RequireNone> </RequireAll>
As you can see, we’ve combined several different sets of requirements to ensure that the user is in the sales or admin group, isn’t a temporary employee, and various other combinations.
As with other features that are new in 2.4, you’ll start to see more and more examples of their use as time goes by. We hope that this has given you a taste of what the new syntax makes possible that was difficult, or even impossible, before.
Over the coming weeks, I’m going to be writing several articles about new features in Apache httpd 2.4. To me the most compelling reason to upgrade to Apache 2.4 today is the <If> directive, so that’s where I’ll start.
Related documentation:
This is something that people have been asking for since the very first day I was involved in Apache stuff – the ability to insert conditional statements in configuration files. And now that it’s here, it’s everything we wanted. Even a bit more.
The <If> directive may be used in all contexts (server config, virtual host, directory, .htaccess) and is evaluated at request time to effect the behavior of the server.
Some of the things you might use this directive for, you’ve been using mod_rewrite for up until now, so one of the side-effects of this directive is that we can reduce our reliance on mod_rewrite’s complex syntax for common situations. Over the coming months, more examples will be added to the documentation, and we’ll have a recipe section with many of the same sorts of scenarios that are in the mod_rewrite recipe section.
Let’s start with a few simple examples so that you can see how it might be used. Consider a case where you have a website, www.wooga.com, and you want to compel people to use the www prefix for all requests. In the distant past, you may have used mod_rewrite for this, but here it is stated more clearly with the If directive:
<If "$req{Host} != 'www.wooga.com'">
RedirectMatch (.*) http://www.wooga.com$1
</If>
In plain language, that says "if the host request header isn’t www.wooga.com, redirect the request to www.wooga.com."
In fact, most of the commonest uses of mod_rewrite can now be replaced with the If directive, making them easier to read, and, therefore, less prone to error, and the redirect looping that so often plagues RewriteRule-based solutions.
For more complex scenarios, there’s also <ElseIf> and <Else> directives, so that you can create multi-step if … elseif … elseif … else logic flows in your configuration files.
These directives may be used in any scope – main configuration, virtual hosts, directories, or .htaccess files – and so give you significantly more power for conditional configurations than you ever had before.
The term in the If statement can be any request header ($req) or environment variable ($env), or many other values. Expressions in these comparisons can be fairly complicated, as they can use the new expression syntax which is another major enhancements in httpd 2.4, and an article for another day.
As with many features that are brand new in 2.4, you can expect more detailed official documentation in the near future, complete with many examples. For now, I’d encourage you to study the expression syntax documentation, and experiment.
Over the coming months, I’ll be writing a series of article highlighting the new and improved features of Apache HTTP Server 2.4. I don’t have a particular schedule for this, but I feel that each of these new features merits a dedicated article. Some of these articles will end up being part of the official documentation, so you could also think of this as my scratchpad for that.
First on my list is the <If> directive container, and the amazingly cool things that you can do with it which were rather difficult in the past. Anything that makes mod_rewrite less necessary is a winner in my book.
The Apache Software Foundation Celebrates the 17th Anniversary of the Apache HTTP Server with the release of v2.4
World’s most popular Web Server powers nearly 400 million Websites across the globe
Forest Hill, MD – 21 February 2012 – The Apache Software Foundation (ASF), the all-volunteer developers, stewards, and incubators of nearly 150 Open Source projects and initiatives, today announced version 2.4 of the award-winning Apache HTTP Server. Celebrating its 17th anniversary with an all-time record of nearly 400 million Websites powered worldwide[1], the Apache HTTP Server has been the most popular Web server on the Internet since April 1996.
“It is with great pleasure that we announce the availability of Apache HTTP Server 2.4”, said Eric Covener, Vice President of the Apache HTTP Server Project. “This release delivers a host of evolutionary enhancements throughout the server that our users, administrators, and developers will welcome. We’ve added many new modules in this release, as well as broadened the capability and flexibility of existing features”.
Numerous enhancements make Apache HTTP Server v2.4 ideally suited for Cloud environments. They include:
• Improved performance (lower resource utilization and better concurrency)
• Reduced memory usage
• Asyncronous I/O support
• Dynamic reverse proxy configuration
• Performance on par, or better, than pure event-driven Web servers
• More granular timeout and rate/resource limiting capability
• More finely-tuned caching support, tailored for high traffic servers and proxies.
Additional features include easier problem analysis, improved configuration flexibility, more powerful authentication and authorization, and documentation overhaul. For the complete feature list, please see http://httpd.apache.org/docs/2.4/new_features_2_4.htm
The Apache Web Server began as a fork (an independent development stream) of the NCSA httpd Web server created by Rob McCool at the National Center for Supercomputing Applications (NCSA). After McCool’s departure from NCSA in 1994, an online community of individuals called the Apache Group formed to support and enhance its software via email collaboration. The Apache Group’s founding members included Brian Behlendorf, Roy Fielding, Rob Hartill, David Robinson, Cliff Skolnick, Randy Terbush, Robert Thau, and Andrew Wilson.
Within less than a year of the Apache Group’s formation, the Apache server surpassed NCSA httpd as the #1 server on the Internet –and remains so to this day. In March 1999, members of the Apache Group formed The Apache Software Foundation to provide organizational, legal, and financial support for the Apache HTTP Server.
Availability and Oversight
Apache HTTP Server software is released under the Apache License v2.0, and is overseen by a self-selected team of active contributors to the project. A Project Management Committee (PMC) guides the Project’s day-to-day operations, including community development and product releases. Apache HTTP Server source code, documentation, mailing lists, and related resources are available at http://httpd.apache.org/
About The Apache Software Foundation (ASF)
Established in 1999, the all-volunteer Foundation oversees nearly one hundred fifty leading Open Source projects, including Apache HTTP Server — the world’s most popular Web server software. Through the ASF’s meritocratic process known as “The Apache Way,” more than 350 individual Members and 3,000 Committers successfully collaborate to develop freely available enterprise-grade software, benefiting millions of users worldwide: thousands of software solutions are distributed under the Apache License; and the community actively participates in ASF mailing lists, mentoring initiatives, and ApacheCon, the Foundation’s official user conference, trainings, and expo. The ASF is a US 501(3)(c) not-for-profit charity, funded by individual donations and corporate sponsors including AMD, Basis Technology, Cloudera, Facebook, Google, IBM, HP, Hortonworks, Matt Mullenweg, Microsoft, PSW Group, SpringSource/VMware, and Yahoo!. For more information, visit http://www.apache.org/.
“Apache”, “Apache HTTP Server”, and “ApacheCon” are trademarks of The Apache Software Foundation. All other brands and trademarks are the property of their respective owners.
[1] Source: Netcraft Web Server Survey http://news.netcraft.com/archives/category/web-server-survey/