Re: Apache 2.4 adoption
How many Linux distros ship httpd 2.4? Fedora 18 is their first release to include httpd 2.4. Since Fedora is often an early adopter of new releases, I expect 2.4 hasn't trickled down to other distributions yet, e.g. RHEL, CentOS. It looks like 2.4 has only got as for as Debian experimental: http://packages.debian.org/search?keywords=apache Ubuntu haven't adopted it yet: http://packages.ubuntu.com/search?keywords=apache Of course the next question could be why have distros not adopted 2.4, is it just a matter of time or are there other factors? From: Kevin A. McGrail kmcgr...@pccc.com To: dev@httpd.apache.org; William A. Rowe Jr. wr...@rowe-clan.net Sent: Wednesday, 6 February 2013, 0:47 Subject: Re: Apache 2.4 adoption I won't be able to make the session but would add that because of a lack of mod perl support with 2.4, we have not fully embraced it. Might be others in a similar boat! Regards, KAM William A. Rowe Jr. wr...@rowe-clan.net wrote: I've found the following data summary very useful in terms of drill-down capability; http://w3techs.com/technologies/details/ws-apache/2.2/all http://w3techs.com/technologies/details/ws-apache/2.4/all while their breakdown/segmentation tabulations provide some interesting data such as; http://w3techs.com/technologies/breakdown/ws-apache/operating_system The very limited 'free' tabulation remaining from SecuritySpace seems to back up this assessment; http://www.securityspace.com/s_survey/data/201301/servers.html There seems to be a worthwhile discussion about the challenges presented by 2.4 which have adversely affected its adoption, during the ApacheCon Hackathon Mon 2/25 in Portland. I'd like to set aside time about 11am for that discussion for anyone who wants to participate. Once we take away some good information from that roundtable, it would be worthwhile to hold a BoF later in the week especially for end users who are looking at or challenged by adopting 2.4.
Re: Inserting protocol filters into chains with no resource filters
- Original Message From: Stefan Fritsch s...@sfritsch.de To: dev@httpd.apache.org Cc: p...@talk21.com p...@talk21.com Sent: Tuesday, 11 January, 2011 22:33:33 Subject: Re: Inserting protocol filters into chains with no resource filters On Tuesday 11 January 2011, p...@talk21.com wrote: I've encountered an issue with add_any_filter_handle(). Let me explain the background. My understanding of filter chains is that they form a linked list with three entry points. The entry points correspond to resource filters, protocol filters and connection filters. Depending on the filters present, these entry points can overlap, but the order must be: resource filters = protocol filters = connection filters. I have a module that sets up a filter chain from scratch, with perhaps unusual characteristics. I've noticed that if the chain has no resource filters and you try to add a protocol filter, then the protocol filter entry point moves to accommodate new filter, but the resource filter entry point remains unchanged. For example, before add_any_filter_handle() the chain looks like this: filter1 (protocol) - resource filters - protocol filters filter2 (connection) - connection filters After adding another protocol filter: new filter(protocol) - protocol filters filter1 (protocol) - resource filters filter2 (connection) - connection filters I'd expect that traversing the chain starting at the resource filters entry point would pass by every filter, hence the expected result would be: new filter(protocol) - resource filters - protocol filters filter1 (protocol) filter2 (connection) - connection filters I've extracted the add_any_filter_handle code from httpd trunk and created a unit test. http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_filter.c ?revision=965325view=co With my patch enabled, add_any_filter_handle() functions as I'd expect. When the patch is disabled, via conditional compilation, the test2() function fails. I'd like to know if there's a valid reason for the current behaviour, or if the fix I've posted is appropriate. I think what you describe is a bug. There is at least one issue with your fix: r_filters and p_filters can be NULL. If I change the if clause in your patch to if (r_filters p_filters *r_filters == *p_filters outf == p_filters) it passes the test suite. Apart from that, I haven't tried to understand add_any_filter_handle() well enough to tell if your fix is correct. I agree, adding checks for non-NULL improves the fix. add_any_filter_handle() is complex, the annotated source shows who has worked on this function. Maybe its authors could review this change. http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_filter.c?annotate=965325
Re: mod_cache: disk layout for vary support
- Original Message From: William A. Rowe Jr. wr...@rowe-clan.net To: dev@httpd.apache.org Sent: Sunday, 10 October, 2010 18:09:23 Subject: Re: mod_cache: disk layout for vary support On 10/10/2010 10:56 AM, Graham Leggett wrote: One of the things that needs to be fixed with mod_cache is the support for caching varying responses. In the current cache, we store it as below, as an additional directory tree below the original URL's directory tree. This wastes lots of inodes, and is very expensive to write. What I have in mind is to move the varied content into the main tree, [...] We reuse the same directory structure in the process, and keep the original QSJf2JA.header file indicating that the URL is a varied URL. +1 Currently the CacheDirLevels and CacheDirLength are also used to calculate the path for the varied entities. What about having separate configuration for the vary sub-directory tree? CacheDirLevels/CacheDirLength will be tuned for storing a huge number of URLs. But how many variants do we expect per URL? A much smaller number. I'd expect you can safely store all variants in a single subdirectory, i.e. VaryCacheDirLevels=0. That way when it comes to retrieving content, once you've parsed the vary file, you've less inodes to deal with before getting to the final content. The directory tree would be: /tmp/cacheroot/ /tmp/cacheroot//1uq /tmp/cacheroot//1uq/w...@d /tmp/cacheroot//1uq/w...@d/Fok /tmp/cacheroot//1uq/w...@d/Fok/HRU /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62 /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header.vary /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header.vary/ thJbK5im1RSzfCKYHquMmA.data /tmp/cacheroot//1uq/w...@d/Fok/HRU/I62/QSJf2JA.header.vary/ thJbK5im1RSzfCKYHquMmA.header Is that better than starting over from the top level to find the varied content? Thanks, Paul
