Re: [RESULT] (Was: Re: [VOTE] Release Apache HTTP Server 2.2.9)
On Fri, Jun 13, 2008 at 3:49 PM, Jorge Schrauwen [EMAIL PROTECTED] wrote: I'd say tomorrow so most mirrors will be synced by then... unless they sync very fast... no idea how fast that is. You can see a histogram of last-sync times near the bottom of this page: http://www.apache.org/mirrors/ Most mirrors sync at least every 12 hours and essentially all sync within 24 hours.
Re: svn commit: r654752 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS modules/generators/mod_cgid.c
On Fri, May 9, 2008 at 8:27 AM, Jeff Trawick [EMAIL PROTECTED] wrote: On Fri, May 9, 2008 at 6:57 AM, [EMAIL PROTECTED] wrote: Author: trawick Date: Fri May 9 03:57:46 2008 New Revision: 654752 URL: http://svn.apache.org/viewvc?rev=654752view=rev Log: backport from trunk: *) mod_cgid: Explicitly set permissions of the socket (ScriptSock) shared by mod_cgid and request processing threads, for OS'es such as HPUX and AIX that do not use umask for AF_UNIX socket permissions. [Eric Covener, Jeff Trawick] *) mod_cgid: Don't try to restart the daemon if it fails to initialize the socket. [Jeff Trawick] A patch for 2.2.8 is in http://people.apache.org/~trawick/cgid_socket_perms.txt and needs to be moved to http://archive.apache.org/dist/httpd/patches/apply_to_2.2.8/ (blush) I don't recall if/how I can log on to archive.apache.org or otherwise put stuff there. Offline hints and/or somebody do the dirty work? Just put it in people.apache.org:/www/www.apache.org/dist/httpd/patches/apply_to_2.2.8/. The archive.apache.org/dist/ directory is an automatic copy of the stuff under www.apache.org/dist/. Joshua.
Re: svn commit: r653856 - /httpd/httpd/trunk/docs/manual/mod/core.xml
On Tue, May 6, 2008 at 1:57 PM, [EMAIL PROTECTED] wrote: +note type=warningtitleNote/title + pThis directive will be ignored in a name-based virtual host context./p +/note That should just be an ordinary note with no type=. warning is for really-important stuff like security problems. (Obviously we should have called it something like important, rather than warning, since you aren't the first to use it that way.) Joshua.
Re: Apache response time
2008/5/4 Niko Wilfritz Sianipar Sianipar [EMAIL PROTECTED]: How to get the response time in the apache log file in msec. Thank you. %D in the logformat string gives you microseconds. Joshua.
Re: IIS6 application pools feature in Apache..
On Wed, Apr 30, 2008 at 5:06 PM, Graham Leggett [EMAIL PROTECTED] wrote: The easiest way to do this would be to run a dedicated httpd process for each application (forming your pool), and then combine them into one website using a standard reverse proxy configuration. http://wiki.apache.org/httpd/DifferentUserIDsUsingReverseProxy Joshua.
Re: svn commit: r644357 - /httpd/httpd/branches/2.2.x/docs/conf/extra/httpd-dav.conf.in
On Thu, Apr 3, 2008 at 11:29 AM, [EMAIL PROTECTED] wrote: Author: wrowe Date: Thu Apr 3 08:28:59 2008 New Revision: 644357 URL: http://svn.apache.org/viewvc?rev=644357view=rev Log: Correct broken configuration in 2.2 - this example didn't run out of the box +AuthDigestProvider file I'll admit I never tested that, but file is supposed to be the default for AuthDigestProvider. Why didn't it work before? Joshua.
Re: Adding stickysession cookie on the proxy
On Thu, Mar 6, 2008 at 3:05 PM, Jim Jagielski [EMAIL PROTECTED] wrote: The advantage of mod_headers is more flexibility that what could be comfortably added to the proxy module itself as well... This comes up maybe once or twice a year... I think I'll add it to my standard Apache 2.2 Proxy module presentation ;) How about adding it to the documentation (or at least the wiki)? Joshua.
Re: r-user not logged for authenticated requests with handlers outside the protected area
On Wed, Feb 20, 2008 at 7:45 PM, Chris Stromsoe [EMAIL PROTECTED] wrote: All requests for php in /opt/html authenticate properly but don't set REMOTE_USER and are logged with r-user == NULL. I'm guessing that's because the handler is not inside the protected directory. Feature or bug? I can provide more detail if that's not eough. Feature. It is explicitly documented in mod_log_config: http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#modifiers Try also dumping all the env variables starting with REDIRECT_ Joshua.
Re: XSS vulnerability in mod_negotiation - status in 2.2.8?
On Feb 5, 2008 5:40 AM, Boyle Owen [EMAIL PROTECTED] wrote: Greetings, Our security guy noticed this alert about a XSS vulnerability in mod_negotiation: http://www.mindedsecurity.com/MSA01150108.html. According to the link, it applies to apache = 2.2.6, so no worries for 2.2.8. However, when I double-check the changelog for 2.2.8 (http://www.apache.org/dist/httpd/CHANGES_2.2.8) there is no specific mention of a patch in mod_negotiation... From a quick inspection of the source code, there was no change to mod_negotiation.c between 2.2.6 and 2.2.8 so can I conclude that the vulnerability is still present in 2.2.8? (ie, can it have been handled at a higher level?) If I remember correctly, the security does not consider this a vulnerability. To do the XSS you need control of filenames on the server. If you have that, you probably have much-more-straightforward ways to steal cookies. There might be a very-few badly-configured sites that are vulnerable to this, so it should be fixed. But it is not a serious security issue. Joshua.
Re: PCRE in Apache?
On Jan 25, 2008 5:28 PM, Chris H. [EMAIL PROTECTED] wrote: Greetings all, I'm toying with the idea of using PCRE in Apache 1.3. I see already that there is support for REGEX in the Configuration.tmpl that permits a choice of bundled or system (if available). But was wondering how hard, or if even reasonable to consider adding the same option to use System PCRE (if available) option. And if so, would it be better in the server, or better as a module. I see also that Apache 2+ has this already. I would greatly appreciate any thoughts/feedback/pointers regarding this. Thank you for all your time and consideration in this matter. Use PCRE to do what? Regular expressions are used for many different purposes in apache. But in general, this sounds like it would be way more difficult that just upgrading to a remotely recent version. Joshua.
Re: Apache 2 IP_Forwarding
On Nov 2, 2007 12:41 PM, Shaw, Dan [EMAIL PROTECTED] wrote: Good Morning, We are trying to identify the following and we have received one response and need to verify. We are looking for feedback or heck even a solution on the following In order to get the IP address of the client, instead of the IP address of the proxy server, the mod_w3c_ip_forwarding.c program can be compiled into Apache 1.3.6. How does one achieve this same functionality in Apache 2.0.X? Specifically - Does Apache 2.0.X already provide this functionality? If not, will mod_w3c_ip_forwarding.c work with Apache 2.0.X? If not, is there a similar program for Apache 2.0.X? Why are you writing to the dev list? If you need additional feedback, please continue your thread on the users list. (Also, you received more than one response. I told you that you will need mod_extract_forwarded if you want to pretend that the contents of the X-Forwarded-For header are the real client IP address. There is a version for 2.x.) Joshua.
Re: Strange access log entry repeating
On 10/15/07, Marten Lehmann [EMAIL PROTECTED] wrote: I'm using httpd-2.2.4. If you don't have an idea, I can maybe track it down a bit further. But so far this simpelst thing I can explain is: With a pretty standard httpd.conf there is no long entry unless someone actually calls a URL. But once I include the configuration lines above and restart apache, strange log lines appear. Note: There is always an error 400. And the URL called is always GET /, not even GET / HTTP/1.0 or so. See: http://wiki.apache.org/httpd/InternalDummyConnection When the default vhost is SSL, you get the 400 because apache doesn't bother doing ssl negotiation -- it just sends an ordinary http request. But this doesn't matter since the request only needs to wake up the process, nothing else. Joshua.
Re: AP_CONN_CLOSE on force-response-1.0
On 10/9/07, Jim Jagielski [EMAIL PROTECTED] wrote: All I'm saying is that, iirc, the intent of force-response-1.0 is to force a 1.0 response and disable keepalives... it was designed to work around buggy browsers that had problems with 1.1 features, including wonky 1.0-type keepalives. No, you are thinking of downgrade-1.0 or nokeepalive. force-response-1.0, according to the docs, is only supposed to change the response-line, and nothing else. It was specifically designed for stupid clients (AOL) that couldn't handle a response with HTTP/1.1 in the response line, even if only HTTP/1.0 features were used. See: http://httpd.apache.org/docs/2.2/env.html#special Joshua.
Re: How to kill 1.3?
On 10/3/07, Roy T. Fielding [EMAIL PROTECTED] wrote: I don't care what the uptake graph says. I don't care what people outside this project mailing list think, period, about this project. And if five years from now there are three or more Apache committers that want to release 1.3.x, then no stupid marketing announcement is going to stop them. We have better things to do. Let's do those things and stop worrying about other people's perceptions. I agree, with a caveat. I think that we are doing a disservice to our users if we don't communicate to them the attitude of the people on this mailing list towards 1.3. In particular, I don't think our main page or download page is currently clear enough about the status of 1.3 development. I think we should say something like: The Apache HTTP Server version 1.3 is not recommended and is not being actively developed. It /may/ continue to receive updates for major security issues, but other updates are unlikely. We recommend that you choose version 2.2 in its place. Unlike Bill's manifesto, this statement is not meant to constrain the developers, but simply to communicate the current state of development to the users. Joshua.
Re: Proxying OPTIONS *
On 10/1/07, Jim Jagielski [EMAIL PROTECTED] wrote: I know Roy's already reported the proxy error as bogus, but I think the OPTIONS * BUGZ report is also bogus. As a test, I assumed that both www.apache.org and apache.webthing.com are reasonably configured servers: www.apache.org is using a config built from the 2.0 default, where Directory / was not restricted. To hit the (alleged) bug, you'd need to test on a server using the 2.2 default: Directory / Order deny,allow Deny from all /Directory (I haven't done this testing myself, so I have nothing else to contribute on the issue.) Joshua.
Re: Proxying OPTIONS *
On 10/1/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: But I'm rather against breaking this in 2.2 to solve (what are, today) configuration quirks. Let's get this right for 2.4 and call out the change very clearly in (our overlong) CHANGES? I'm thinking of a new second-priority category after SECURITY:, e.g. CONFIG: or MUSTNOTE: so administrators who migrate aren't surprised. Should be in this, rather sparse file: http://httpd.apache.org/docs/trunk/new_features_2_4.html Joshua.
Re: Proxying OPTIONS *
On 10/1/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Joshua Slive wrote: Should be in this, rather sparse file: http://httpd.apache.org/docs/trunk/new_features_2_4.html But it's not a feature-per say. It's a bugfix, so the name new_features doesn't tell admins they have to adopt a change (new feature implies there's a goodie I can exploit if I choose to)... Sorry, my little tiny contribution to this thread was less than useful. I meant the even more sparse: http://httpd.apache.org/docs/trunk/upgrading.html ...and hiding in docs isn't really the best place for major config-changing bullet points that will break their previously working, 2.2 server in some unexpected way. Hmmm... Hiding in an enormous, mostly-indecipherable CHANGES file is better? I think the upgrading guide is exactly where that stuff belongs. Joshua.
Re: Patching PR#13986
On 9/26/07, Nick Kew [EMAIL PROTECTED] wrote: We really need to fix this issue of inappropriate DefaultTypes. An approach that deals with this without loss of back-compatibility is to hand the decision to systems administrators: #to suppress setting content-type when the server has no information DefaultType ! +1 on concept, but I'd prefer DefaultType none, which is more readable and I believe equally unlikely to show up in a real content-type. Joshua.
Re: What is httpd -X?
On 9/20/07, Ashwani Kumar Sharma [EMAIL PROTECTED] wrote: What is httpd –X See: http://httpd.apache.org/docs/2.2/programs/httpd.html Whether I can use this –X option for the deployment. The better question is: why would you want to? You mention nothing about what problem you are trying to solve, so there isn't much advice we can give you. But I can't imagine many problems where running a single-process, non-detached web server in production would be the right solution. Joshua.
Re: What is httpd -X?
On 9/20/07, Ashwani Kumar Sharma [EMAIL PROTECTED] wrote: I want to start the httpd web server through my own application and then I would like to shut down the web server once I wish to bring my application down, normally or abnormally (in case). Will it be fine if I spawn the Apache web server by httpd -X option? Would it create some unforeseen prob in my application. All this I am doing so that I can kill the apache web server through kill(pid, sigkill) option. Killing two httpd processes after spawning two httpd processes is difficult. No, this is not the right solution. As has already been pointed out in this thread, -DNO_DETACH is available if you just don't want apache detaching. But even easier, you only have to kill one single process (the apache parent process written to the httpd.pid log file) and that process will take care of killing off all the rest. But you do it withh SIGTERM, not SIGKILL, to give the process a chance to do the cleanup. Joshua.
Re: Increasing the size of allow_options_t and overrides_t
On 9/1/07, Graham Leggett [EMAIL PROTECTED] wrote: Hi all, I am working on a patch that needs to widen the two bitmaps below, as they have run out of bits. Would such a change be backport-able to v2.2, and what kind of MMN bump would it need if so? I think that'll break the binary API, which would make in non-backportable. But in any case, whenever expanding Options has come up in the past, someone has pointed out that it is almost always better to simply create a new directive. The Options directive is one of the most confusing things for httpd users, and adding to it certainly won't help. If we were starting from scratch, I'm pretty sure we wouldn't include an Options directive at all. Joshua.
Re: About modules/metadata/mod_expires.c (apache 2.2)
On 8/26/07, Julien Perez [EMAIL PROTECTED] wrote: Hello everybody, While setting up a reverse proxy squid + apache w/ mod_expires.c in order to decrease the load on the web server, I discovered that mod_expires.c was working by checking the mimetype of the content generated by the web server ( i.e. cgi or static file) and not the mimetype of the file that was used to generat the output. Could someone explain me why it is so ? I believe that is exactly what most people expect and want. For example, people want different expiration times for html versus gif versus css. Many people would be annoyed if html generated by cgi was not matched. For what you want, you can use ExpiresDefault scoped in a Directory or Files section to apply only to the specific content that you need. Joshua.
Re: default content type
On 8/25/07, Roy T. Fielding [EMAIL PROTECTED] wrote: For standards conformance, I am going to start removing the default content type settings from trunk tomorrow. http://issues.apache.org/bugzilla/show_bug.cgi?id=13986 If you have any problems with that, let them be known here. +1 Joshua.
Re: Conditional RequestHeader patch not reflected in documentation?
On 8/10/07, Rich Bowen [EMAIL PROTECTED] wrote: Received this query from a friend and colleague: ... I've been working on an issue at work, where we're trying to remove some headers from a (proxied) request. Whilst I was looking for a solution I came across this patch: http://mail-archives.apache.org/mod_mbox/httpd-cvs/200406.mbox/% [EMAIL PROTECTED] but when I looked at the mod_headers docs - http://httpd.apache.org/docs/2.0/mod/mod_headers.html I can't see anything about it. I was wondering if the patch was reversed or wasn't used, or whether the documentation was behind. Looking at the code, I'm not entirely certain if the patch is in there or not. The removed lines are missing, but so are the added lines. Can someone shed any light on this for me, please? Or is this so long ago that it's no longer answerable? From http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/modules/metadata/mod_headers.c it looks like it is in there to me. (Header and RequestHeader processing are identical.) The docs just never got backported to 2.0. Joshua.
Re: Vhosts running as different userids (was: Re: Inclusion of mpm-itk into HEAD)
On 8/5/07, Vegard Svanberg [EMAIL PROTECTED] wrote: * William A. Rowe, Jr. [EMAIL PROTECTED] [2007-08-05 05:15]: I've looked through the archives, but have not seen this mentioned again since then. I was wondering if this has been discussed any further, possibly moved to other mailing lists, and/or if it's been added to a roadmap for future releases. None of the above. There has been activity on the www.apache.org/wiki/httpd site w.r.t. setting up per-user hosts in parallel, but not much else. OK. Say you have a server with 1000 vhosts, what performance penalties must be expected from this solution? Just more memory (and if so, roughly how much)? This question might be better answered on the users list. There is no single answer to that, because it depends on exactly what kind of hosts we are talking about. But in general, 1000 is too many hosts for true isolation on a single box. That is because any decently-performing isolation solution involves keeping a pool of threads/processes available under each userid. And 1000 pools of threads or processes is really going to be at the limit of any reasonable hardware/software. Of course, you could spread the back-ends among many boxes if you wanted, but then it isn't a true name-based virtual hosting solution. So what you are asking about is more a general architecture question than a specific apache configuration issue. But to answer your specific question, if you were serving only static content, then the proxy solution is probably going to use approximately twice as much resources as a standard vhosting setup. But I would expect that normally you are talking about somewhat heavy-weight back-ends. In this case, you will use substantially less than twice as much resources, because the front-end can be very light-weight. Again, there is no single answer. Joshua. It takes a specific developer hacking at a solution, and for the developer to respond to the concerns/criticisms, to ultimately end up with code that we might incorporate in svn trunk. Yes, I'm aware of that. One of the reasons for asking was to check if this is the preferred way of fixing this problem or if there are other (possibly better) suggestions out there. Thank you for your replies. -- Vegard Svanberg [EMAIL PROTECTED] [EMAIL PROTECTED] (EFnet)]
Re: 1.3 bugs
On 8/2/07, Nick Kew [EMAIL PROTECTED] wrote: As for 2.x bugs, there are quite a few which are going to be harder to deal with. Perhaps we want a new Archived status, for PRs which have merit but which aren't going to get 'fixed'. Particularly those with PatchAvailable. I would just use Later. Joshua.
Re: [PATCH]: mod_cache: don't store headers that will never be used
On 7/29/07, Graham Leggett [EMAIL PROTECTED] wrote: Niklas Edmundsson wrote: The solution is to NOT rewrite the on-disk headers when the following conditions are true: - The body is NOT stale (ie. HTTP_NOT_MODIFIED when revalidating) - The on-disk header hasn't expired. - The request has max-age=0 This is perfectly OK with RFC2616 10.3.5 and does NOT break anything. From 10.3.5: If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response. This sinks this, unless I am misunderstanding something. I think his point is that the headers will NEVER be used, so it doesn't matter whether or not you store them in the cache. There is no point in storing the headers just based on the technicality that the spec says to do so if they will never be used for anything. (Or, in other words, even if you are violating the literal spec, you are only doing so with respect to the internal state of the cache -- something that is never visible to the outside world and hence can't really matter for spec conformance.) What needs to be validated is if, in fact, the headers with NEVER be used. Is there any configuration directive or client request that could make mod_cache use headers from the cache when max-age=0? I don't think so. I suspect there is a more robust way of solving this: In order to determine whether the entity was cached in the first place, the cache would have had to read the headers in from disk. Fast forward to after the 304 response was received, we have the headers as received from the backend. Compare these two sets of headers, and if they are equal, there is no need to rewrite them to disk. Nah, I bet there are many times where the two sets of headers will differ (based on Date alone, for example, or Expires, which will get updated to match the max-age=0) but you still don't care about the new headers because they won't be used for future requests. Joshua.
Re: Apache configuration (throughput of connection)
On 6/28/07, Niko Wilfritz Sianipar Sianipar [EMAIL PROTECTED] wrote: I have some questions about apache configuration: 1. Does apache can be configured so he can order the clients according to their throughput? I don't know what you mean by order the clients. 2. How can apache know the throughput of each client that connect to it? By throughput do you bandwidth available between the server and client? There is no way for Apache to know this. There are, however, certain models that will throttle client bandwidth usage to ensure that nobody is hogging all the bandwidth. Check out http://modules.apache.org/. This is something that is often better performed at the (software or hardware) firewall, however. Joshua.
Re: Inclusion of mpm-itk into HEAD
On 6/27/07, Nick Kew [EMAIL PROTECTED] wrote: This is a problem that could be solved by documentation. Maybe not quite as simple, but when the alternative is accepting new connections whilst running as root. Here's a start: http://wiki.apache.org/httpd/Recipes/Privilege_Separation It could use lots of polishing. Joshua.
Re: Inclusion of mpm-itk into HEAD
On 6/27/07, Rici Lake [EMAIL PROTECTED] wrote: If the user servers are listening on high ports, then they can be started as the user/group rather than as root, and the owner could have quite a bit of flexibility in configuring their server. It's quite possible that less reliance on .htaccess files would actually compensate for the additional cost of running multiple server instances. Good point. I moved some of this discussion into its own section, since it applies equally to the main example. I also removed your comments about needing separate LockFile/etc locations, since its not true in recent versions. (These files are created with the pid of the parent process appended to ensure they are unique.) Joshua.
Re: Inclusion of mpm-itk into HEAD
On 6/25/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: That said, have you considered a design where there are separate pools of processes per-user, and these would be dispatched after the headers are processed to the appropriate child? The simplest option is to simply reuse the features that already exist to get that effect: http://wiki.apache.org/httpd/Recipes/Different_UserIDs_Using_Reverse_Proxy It's never going to be as fast as perchild, since it uses inefficient http for the dispatching. But it will beat the pants off of an mpm that serves only one connection per process at the expense of slightly more memory. It would be nice if that could be accomplished with a single instance of httpd and a single config file. Implementing that would probably be simpler than solving the perchild problems. Joshua.
Re: mod_rewrite
On 6/20/07, sonia mukherjee [EMAIL PROTECTED] wrote: Hi All, could any one give me information on whether any Api call is present with Apche 2.2 that gives indication that Rwrite Rule is configured for a particular URL. And if possible with full info on what are the flags that are set (flags like L,P,QSA...) Perhaps you could tell us exactly why you need this and that would help us understand better how to help you. There is no direct API where you can supply a URL and get that exact information. But you can run a sub-request and see if mod_rewrite grabs it. There is also the ever-helpful RewriteLog. Joshua.
Re: [Issue] External links @ the wiki, aka pagechange wars
On 5/24/07, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, On 5/24/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/23/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: We have a serious issue to determine, and I've asked for a 48 hour cooldown of wiki.apache.org/httpd/ to make a decision, and in the meantime asked that the wiki become read-only for the conclusion of this decision. [ X ] Our httpd wiki is open to external resources for httpd. [ ] External httpd resources are prohibited. snip / If a Wiki isn't open to community input ( where community here means *users*, not the typical Apache definition of community meaning the *committers*), then what is it for? Committers can already post to I Agree with Craig. I think there is a clear and reasonable middle ground: External links are encouraged where they add substantial value, but you may not link to your own pages or otherwise seek private benefits from external links. This has been the unwritten rule in the apache httpd docs for as long as I remember. I have personally added many external links to the regular docs to things written by apache contributors, but not to my own pages. Joshua.
Re: [Issue] External links @ the wiki, aka pagechange wars
On 5/24/07, Rich Bowen [EMAIL PROTECTED] wrote: On May 24, 2007, at 04:23, Tony Stevenson wrote: AskApache has had several email conversations with both myself, and Rich. In which he was asked politely, but firmly to not use links to content on his site. NOTE: NOT because external links are bad, but because the articles to which he was linking were misleading, incorrect, and promoted sub- optimal solutions to common problems. The implied endorsement (The Apache docs link to this article, so it must be true) was unfortunate, and undesirable. Although I respect Bill's desire to have this solved apache-wide, I actually think that this case would have been better addressed in the closer confines of [EMAIL PROTECTED] Let's just address this particular case and not worry about the general issue for now. The Apache wiki is not some democratic exercise like wikipedia where we need to treat everyone equally. We are a meritocracy, not a democracy, even on the wiki. Certain people (like Rich) have earned the right to make final decisions about what should be on the wiki. AskApache has not earned that right. The content that he is adding is inappropriate (and violates my suggested policy) for many reasons. I suggest that someone email him and tell him that he is henceforth banned from: 1) Making any links to his personal site; and 2) Reverting any change made by someone else (even if that change is a reversion of his change). If he can't live with those rules, he can be banned for good. If you would like me to send this email (as someone who has not interacted with him before) I'd be fine with that (although I don't know his address). Joshua.
Re: [Issue] External links @ the wiki, aka pagechange wars
On 5/24/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: [for infra, who is bcc'ed - three * bullets below] * ask infra to reopen the wiki to general write access, * aks infra to please revoke AskApache/their ip from the httpd wiki. +1.
Re: mod_rewrite
Cross-posted and already answered on [EMAIL PROTECTED] On 5/23/07, Marco Polo [EMAIL PROTECTED] wrote: I need to change a bahaviour on the rewrite of the apache server. Right now, if I type in a path that does not exist (like /nopage.html) Apache will serve up the 404 page (/html/404.html), but the URL will still read /nopage.html. I need the URL to be /html/404.html Conversely, when someone goes to a page that does exist (/x10) Apache will serve up the redirected page (/landing/index.jsp?wfId=685) We need Apache to instead serve up /x10. Thanks
Re: svn commit: r537429 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h
On 05/12/2007 04:12 PM, [EMAIL PROTECTED] wrote: Author: jim Date: Sat May 12 07:12:24 2007 New Revision: 537429 URL: http://svn.apache.org/viewvc?view=revrev=537429 Log: Add regex pattern matching to ProxyPass, allowing, for example: ProxyPass ~ \.gif balancer://imagecluster On the configuration consistency side, the ~ thing is deprecated everywhere and the standard way to do this is to have a ProxyPassMatch directive (see RedirectMatch, DirectoryMatch, etc). Joshua.
Re: svn commit: r534533 - in /httpd/httpd/trunk: include/http_core.h modules/aaa/mod_access_compat.c modules/aaa/mod_auth.h modules/aaa/mod_authz_core.c modules/aaa/mod_authz_default.c server/core.c s
On 5/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: bnicholes Date: Wed May 2 09:31:39 2007 New Revision: 534533 URL: http://svn.apache.org/viewvc?view=revrev=534533 Log: re-introduce ap_satisfies API back into core and modify how the access_checker, check_user_id and auth_checker hooks are called so that they respect the precedence that is set through the satisfy ALL/ANY directive. This also restores the directives order, allow, deny, satisfyas supported directives rather than being deprecated. These directives still remain in mod_access_compat however. Fine. But then let's just revert mod_authz_host to the 2.2 version and delete mod_access_compat. (Or, in other words, rename mod_access_compat to mod_authz_host.) I don't see the reason for having two supported ways of doing the same thing. Joshua.
Re: svn commit: r534533 - in /httpd/httpd/trunk: include/http_core.h modules/aaa/mod_access_compat.c modules/aaa/mod_auth.h modules/aaa/mod_authz_core.c modules/aaa/mod_authz_default.c server/core.c s
On 5/2/07, Brad Nicholes [EMAIL PROTECTED] wrote: Yeah, that's where I mentioned that things might look a little confusing. There actually is a good reason to have both and yes some of the functionality can overlap. The reason for having mod_authz_host is so that host, IP, ENV, etc. can be used during authorization as well. This really wasn't as issue in 2.2 because the AND/OR/NOT logic didn't exist yet. Now that you can apply this type of logic to authorization, allowing host, IP, ENV, etc. to be part of that, make sense. If we moved mod_authz_host back to the 2.2 version, in the first place it would no longer be authz but just mod_access again and you wouldn't be able to include host, IP, ENV, etc. as part of an authorization rule. But I agree that mod_access_compat name no longer makes sense. What kinds of configurations are we actually talking about where Require ip could do things that Order/Allow/Satisfy could not? I guess you are talking about things like SatisfyOne SatisfyAll Require user john Require ip 192.0.0 /SatisfyAll SatisfyAll Require user bob Require ip 191.0.0 /SatisfyAll /SatisfyOne Is that kind of configuration really common enough to justify the added complexity of two different access-control systems? (It can be accomplished in current versions using some Alias/Location hacks or with mod_rewrite.) My opinion is that either we get rid of Require ip or we fix the hook ordering so that Order/Allow/Satisfy/etc can really be deprecated. Joshua.
Re: SatisfyOne
On 4/27/07, Brad Nicholes [EMAIL PROTECTED] wrote: It's beginning to look like Order, Allow, Deny, Satisfy can't be deprecated after all. However I still think that there is a usefulness for the same type of authorization rules defined by require. I don't really understand why you say this. Isn't it just a question of defining the order of evaluation of SatisfyOne blocks? And the proper order seems quite straight-forward to me. Joshua.
Re: Apache Http Server Authentication/Authorisation
On 4/27/07, FORAMITTI Laurent [EMAIL PROTECTED] wrote:
So I would like to know how is it possible to configure Apache to send some
informations about the authenticated user to my AppServer ?
Is it possible to add some values to the http header before that the mod_jk
or mod_wl forward the request to my AppServer ?
In a modern version of apache, something like this might work:
RewriteEngine On
RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule .* - [E=RU:%1]
RequestHeader add REMOTE_USER %{RU}e
(It would work in general with a standard reverse proxy. I'm not sure
if it will work with mod_jk.)
Joshua.
Re: SatisfyOne
On 4/27/07, Patrick Welche [EMAIL PROTECTED] wrote: I expected not to be prompted to login by the above configuration. (also tried AuthBasicAuthoritative Off, and have read the fine manual..) Just to eliminate the obvious, have you actually checked the access_log to verify that the IP address/hostname reported there match your Require directives? (For example, if you are testing on the same host, you may be coming in over the loop-back 127.0.0.1/localhost.) Otherwise, I agree that you shouldn't be getting a login prompt. Joshua.
Re: inconsistency in the Order documentation
On 3/26/07, Joe Schaefer [EMAIL PROTECTED] wrote: Since forever, the documentation for Order claims this: Yes, it's broken. It hasn't been that way forever, just since we tried to improve the Order docs last year. I don't think a patch is really necessary -- it is an easy enough fix. I'll see if I can find time to put my apache svn stuff back in order tomorrow if nobody else gets to it. Joshua.
Re: mime-types
On 3/23/07, System Support [EMAIL PROTECTED] wrote: Randomly the mime-type of my .css files changes from text/css to text/plain. There were a couple of similar bugs reported against caching, but they are shown as being fixed. I did try disabling caching, but it did not seem to help. I don't see why you are starting this discussion here rather than on the users list. But certainly, notwithstanding your comment above, caching is the most likely culprit here. If you are using caching, you should certainly upgrade to version 2.2. (And even in 2.2, mod_disk_cache seems quite a bit more stable than mod_mem_cache.) Joshua.
Re: Apache dev site outdated
On 3/21/07, Jan van den Berg [EMAIL PROTECTED] wrote: http://httpd.apache.org/dev/patches.html So who keeps this page up to date? Any reason why this info isn't yet updated? Because nobody has submitted a patch. (Kind of a circular problem, I realize ;-) Feel free to contribute. Joshua.
Re: The right way to report problems (was: uninitialized variable in ap_directory_walk)
On 3/15/07, Torsten Foertsch [EMAIL PROTECTED] wrote: The bug is simple, the patch is simple. Why haven't I got a single reply to my mail? The bug is also still marked as new. What is the right way to report problems? You're doing fine. See: http://httpd.apache.org/dev/patches.html#ignored Joshua.
cleaned up dist/httpd/binaries
I just deleted all our binary releases from before 2005 that were sitting in our recommended releases directory. They are, of course, all still available from archive.apache.org. With the exception of a few platforms, we just aren't in the business of providing binaries anymore. I don't think that is a particular problem. But it is a problem to leave a bunch of outdated releases in a place that implies that they should be used. Joshua.
Re: Determining Apache version uppon compilation of module ?
On 3/6/07, Joost de Heer [EMAIL PROTECTED] wrote: Xavier Beaudouin schreef: Hello, I am trying to find a portable way to find what is the version of apache during compilation of a third party module. In include/ap_release.h, the macros AP_SERVER_MAJORVERSION_NUMBER, AP_SERVER_MINORVERSION_NUMBER and AP_SERVER_PATCHLEVEL_NUMBER are defined. Also see MODULE_MAGIC_NUMBER (major and minor) from ap_mmn.h, which is a better way to determine API-compatibility. Joshua.
Re: How to cache the responses for XMLHttpRquest
On 3/5/07, Erica Zhang [EMAIL PROTECTED] wrote: Hi, I want to cache the responses for XMLHttpRequest, that is dynamic content. I have configureed http.conf using Expires to add headers to those responses. However, I still could not find those responses to be able to be cached by use of web browser. This sounds like a question for the users list rather than the dev list. When you ask there, try posting a complete set of response headers. Joshua.
Re: Questions on configuring Apache Server
On 2/26/07, Erica Zhang [EMAIL PROTECTED] wrote: Hi, I am developing some component, which need Apache to be able to listen to two ports, instead of only one default port. I do not know if there is some way to configure Apache http server to work in this way. I do not want to configure it to be virtual host. Listen 80 Listen 81 in httpd.conf should do the trick. Or if not, you need to better specify what you are trying to do. Joshua.
Re: Redesigning Limit from the ground up.
On 2/13/07, Nick Kew [EMAIL PROTECTED] wrote: Location /limited/ methods=GET POST HEAD I like that a lot. It makes it clear that methods is an option (and hence doesn't generally need to be there), and skirts the whole ordering mess you get by adding a Method container. Directory /dir/ -- Section filepath = /dir/ Location /loc/ -- Section urlpath = /loc/ Files pattern-- Section relpath = pattern FilesMatch regex -- Section relpath ~ regex Limit GET POST -- Section methods = GET POST ... etc ... Generalising to Section somepath=... methods=..., and to support things like negation. Possibly also drop the confusingly markup-like syntax: BEGIN filepath=/dir/ ... END I hate all that. Although Location/Directory/etc are certainly confusing, I don't see how the above is that much clearer. People are still going to need to read the docs to understand what urlpath and filepath mean. And how does the ordering work? And can you arbitrarily combine filepath/relpath/methods/etc in the same section? Just a big mess, as far as I can tell. And I don't see any point in making massive changes to the config-file format unless there are large concrete gains to be had. It is not only a question of converting old config files to the new format. More difficult is retraining everyone who knows and loves (or hates) the old format. Incremental improvements are great! Joshua.
Re: mod_cache: MISS or HIT
On 2/12/07, Dziugas Baltrunas [EMAIL PROTECTED] wrote: I'm trying to figure out the way how to put information in access log (via mod_log_config) whether the request was a cache hit or miss (similar to what squid does - TCP_MISS and TCP_HIT). I think this information is necessary for any proxy server (or acting like it) and it's always wise to know hit/miss ratio. You can log the Age HTTP response header for this. If it is present, you have a cache hit, and if not, a miss. Of course, this probably wouldn't be reliable if your cache was in front of another cache. But it works in most circumstances. Joshua.
Re: Large Resource Consumption by One User Access to mp3 File
On 2/8/07, Greg Sims [EMAIL PROTECTED] wrote: This consumption of server resource by one user is unfair to everyone else trying to use http at the same time. Is it possible to control resource allocation so that it is fair to all users? The user in question is using some kind of download accelerator that uses multiple byte-range requests to access the same file simultaneously over multiple connections. In general, these accelerators are designed simply to squeeze out other users and hence get faster downloads. It should be considered and handled like a denial-of-service attack. Some documentation on that is here: http://httpd.apache.org/docs/trunk/misc/security_tips.html#dos In general, either use a firewall to restrict number of connections per IP, or use a third-party module to do the same. See http://modules.apache.org/ Joshua
Re: Large Resource Consumption by One User Access to mp3 File
On 2/8/07, Greg Sims [EMAIL PROTECTED] wrote: This consumption of resource seems unfair to other users that are trying to use the system at the same time. Is it possible to control resource allocation so that it is fair to all users? Is there something about the response I made to your [EMAIL PROTECTED] cross-post that you didn't understand or that you wanted clarification of? As I said: The user in question is using some kind of download accelerator that uses multiple byte-range requests to access the same file simultaneously over multiple connections. In general, these accelerators are designed simply to squeeze out other users and hence get faster downloads. It should be considered and handled like a denial-of-service attack. Some documentation on that is here: http://httpd.apache.org/docs/trunk/misc/security_tips.html#dos In general, either use a firewall to restrict number of connections per IP, or use a third-party module to do the same. See http://modules.apache.org/ Joshua
Re: Large Resource Consumption by One User Access to mp3 File
On 2/8/07, Joshua Slive [EMAIL PROTECTED] wrote: On 2/8/07, Greg Sims [EMAIL PROTECTED] wrote: This consumption of resource seems unfair to other users that are trying to use the system at the same time. Is it possible to control resource allocation so that it is fair to all users? Is there something about the response I made to your [EMAIL PROTECTED] cross-post that you didn't understand or that you wanted clarification of? Oops. This one is to the dev list too. You seem to just be ignoring responses in general.
Re: IE7 wrecks language negotiation
On 12/11/06, Fenlason, Josh [EMAIL PROTECTED] wrote: Is there any way Apache could do the following? 1. Search for a match in the language and language-locale list the client provides 2. If no match was found above, strip off the locale and try again. 3. If there still isn't a match, use the server's default language. That way if the server's default is en but has content for en, de, and fr, and the client specified de-CH, de-AT, and fr-CA, de would be served instead of defaulting to en. That would seem to be more useful to the client. As of Apache 2.2.3, that scenario would end up serving en. Hmmm, I haven't looked at the code in a while, but I was under the impression it did that already. Are you saying that the ordering of the fallback list (of languages with locale stripped of) is by the LanguagePriority directive rather than by the Accept-Language priority? If so, I agree that should be changed. Joshua.
Re: IE7 wrecks language negotiation
On 12/11/06, Fenlason, Josh [EMAIL PROTECTED] wrote: I swear that's the behavior I was seeing, but I must have had something messed up. I just tested to verify my complaint and it appears to be working the way I said I wanted it to. Not sure what I messed up, but I must have gotten confused when I was testing. Sorry for bringing up an issue that isn't an issue. I'll go hide in embarrassment. :) Thanks for the help. Okay. And your thought points out that my whole rant was probably misplaced. It is true that IE7 is going backwards in spec-conformance, but it will only be a problem if people mix language tags with and without locale. In the case where the browser uses only tags with-locale, and the server uses either all tags with-locale or all tags without-locale, things should work right based on our previously-included work-arounds. So although IE7 will brake a bunch of reasonable configs, it probably isn't serious enough to warrant changing anything in apache. Joshua.
IE7 wrecks language negotiation
Following up on a question on the users list, I found this blog entry: http://blogs.msdn.com/ie/archive/2006/10/17/accept-language-header-for-internet-explorer-7.aspx which says that IE7 now uses only language/locale pairs in the Accept-Language header. They follow this up with: If a given server is only interested in the user's language and not the locale, it can ignore the locale portion by simply truncating the code at the first dash. This tells server to ignore RFC2616 section 14.4 if they wish to work with IE7. The effect of this is that users who specify more than one acceptable language in IE7 aren't going to get the one they really prefer in many cases when working with HTTP/1.1 compliant servers (like apache httpd). (If only one language is selected, things should work okay because we added a work-around for this in 2.0. But it is impossible to work-around the problem with multiple languages and still follow the RFC.) It would be possible to add a BrowserMatch-settable variable to do the HTTP-breaking recommended by Microsoft, but I don't know if it is worth it. Joshua.
Re: vote on concept of ServerTokens Off
On 12/6/06, Jeff Trawick [EMAIL PROTECTED] wrote: We're up to two great answers to disable some output from the server that isn't required by the HTTP protocol anyway: 1) modify the source 2) install third-party module My support for the idea has nothing to do with improving the operation of the server for users. I support it to make this silly issue go away so we can move on to more interesting things. If you add up the time spent debating this issue on this list, the users list, and the bug database in the last 10+ years, I think it would make you a little sad. Joshua.
Re: vote on concept of ServerTokens Off
On 12/5/06, Joe Orton [EMAIL PROTECTED] wrote: On Tue, Dec 05, 2006 at 06:39:30AM -0500, Jeff Trawick wrote: A lot of opinions were offered back in August. Some were negative but I don't see anything that looks like a veto. (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/[EMAIL PROTECTED]) A concern with the logging of server version has since been resolved, but implementation of the original feature died. Before Sebastian Nohn's patch is revised to fit in with the subsequent changes, I'd like to confirm that nobody has a strong (veto) objection to the feature, and that those in favor clearly out number those against. +1. Should be documented as a bad idea as Joshua notes in that thread. +1 Joshua.
Re: Some authorisation clarification
On 11/29/06, Graham Leggett [EMAIL PROTECTED] wrote: On Wed, November 29, 2006 2:19 pm, Nick Kew wrote: When the configuration is merged, the one that appears later in httpd.conf overrides the other where there is conflict. What constitutes a conflict? What Satisfy value are you using? The config looks like this: # Password protect bugzilla with native LDAP plugin Location /bugzilla AuthType Basic AuthName User principal name AuthLDAPEnabled on AuthLDAPBindDN zzz AuthLDAPBindPassword zzz AuthLDAPURL ldap://zzz:3268/?userPrincipalName,mail,cn?sub AuthLDAPAuthoritative on require valid-user Satisfy all /Location # Password protect this entire website using Redhat LDAP plugin Location / AuthName Username AuthzLDAPMethod ldap AuthzLDAPAuthoritative on AuthzLDAPServer zzz:3268 AuthzLDAPUserBase zzz AuthzLDAPUserKey sAMAccountName AuthzLDAPUserScope subtree AuthzLDAPBindDN zzz AuthzLDAPBindPassword zzz AuthType basic require valid-user Order allow,deny Allow from 127.0.0.1/32 10.182.227.16 Satisfy Any /Location If I swap the two Locations around, the effect is the same - / always wins. The Order/Allow stuff in / will apply to both places because it isn't overridden in /bugzilla. Easy fix: Use LocationMatch ^/(?!bugzilla) instead of Location /. Joshua.
Re: svn commit: r467326 - in /httpd/httpd/trunk: ./ docs/manual/mod/ include/ modules/ssl/ server/
On 10/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: + dtcodesem/code/dt + ddThis directive tells the SSL Module to pick the best semaphore + implementation available to it, choosing between Posix and SystemV IPC, + in that order. It is only available when the underlying platform and + glossaryAPR/glossary supports at least one of the 2./dd +1 on the idea. Two doc comments: 1. You should mention the default lockfile name if it is omitted in the arguments. 2. You probably don't mean SSL Module above. Joshua.
Re: svn commit: r449514 - in /httpd/httpd: branches/2.2.x/docs/manual/mod/core.xml trunk/docs/manual/mod/core.xml
On 9/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: niq Date: Sun Sep 24 15:29:59 2006 New Revision: 449514 URL: http://svn.apache.org/viewvc?view=revrev=449514 Log: Add extra explanatory clause to VirtualHost docs Modified: httpd/httpd/branches/2.2.x/docs/manual/mod/core.xml httpd/httpd/trunk/docs/manual/mod/core.xml Modified: httpd/httpd/branches/2.2.x/docs/manual/mod/core.xml URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/docs/manual/mod/core.xml?view=diffrev=449514r1=449513r2=449514 == --- httpd/httpd/branches/2.2.x/docs/manual/mod/core.xml (original) +++ httpd/httpd/branches/2.2.x/docs/manual/mod/core.xml Sun Sep 24 15:29:59 2006 @@ -3255,7 +3255,7 @@ liThe IP address of the virtual host;/li liA fully qualified domain name for the IP address of the - virtual host;/li + virtual host (not applicable to NameVirtualHosts);/li That's not strictly true, as far as I know. Namevhosts will still work if the reverse DNS of the name in the VirtualHost block maps to the IP specified in NameVirtualHost. I would replace that with simply (not recommended), since we advise people to never use hostnames there, whether or not they are using name-based vhosts. Joshua.
Re: [Vote] create [EMAIL PROTECTED]
On 9/1/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Project Committee Members... Adopt [EMAIL PROTECTED], seeded from [EMAIL PROTECTED] current subscribers, for module authors to use for peer developer support? (API 'users', essentially.) +1 Joshua.
Re: Upgrade 2.0.55 - 2.0.59 hangs SSL server
On 8/28/06, Henk Fictorie [EMAIL PROTECTED] wrote: Hi, We tried to upgrade our Apache server from 2.0.55 to 2.0.59. For HTTP traffic this was successful. However for HTTPS the server would hang after a couple of hours (serveral hundred thousands request). Our HTTP and HTTPS servers are different unix processes. Nothing is logged in the error logfiles, the server just stops to accept new connections. When I try to connect to the server with the openssl command, I get the CONNECTED message, but the SSL handshake does not take place. Here's instructions on how to debug hung servers: http://httpd.apache.org/dev/debugging.html#backtrace Joshua.
Re: mod_define ported to httpd 2.0/2.2
On 8/25/06, Rainer Jung [EMAIL PROTECTED] wrote: I put the code up on http://people.apache.org/~rjung/mod_define/ Comments are welcome. For big sites and well trained admins having an external tool like m4, scripting languages, ant etc. might be the better way to use config templates. But for a couple of easier use cases and less skilled admins, mod_define seems to be easily usable and makes mod_macro more powerful. Isn't this all sort-of obsoleted by the undocumented fact that httpd 2.x already resolves env variables in the config file. (Not that I think that is a particularly good idea, but...) Joshua.
Re: 1.3 modification question
On 8/22/06, hbeaumont hbeaumont [EMAIL PROTECTED] wrote: Are there any obvious flaws? Horrible performance? Thanks for any comments or direction to a better place to ask. Search the archives of this list and the users list for any thread mentioning perchild. You'll find the challenges thoroughly discussed. This is all for 2.x, of course. Everything would be much worse in 1.3 because fo the less-flexible and less-modular code base. Few people are interested in hacking on 1.3 anyway. It hasn't had significant development in over four years. Joshua.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On 8/20/06, Carsten Wiedmann [EMAIL PROTECTED] wrote: You have some examples? http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0017 A HTTP server must process the abs_path from an URI in a case-sensitive manner. Thus with a case-sensitive filesystem it's enough to build a canonical / normalized path and ask the system: You have this file?. With a case-insensitive/preserving filesystem you must also compare the realpath of a file with the canonical / normalized path from the request. That's really basic understanding. And it's not new that some systems, like Windows, have a case-insensitive filesystem or other differences to a normal *nix filesystem. A software must respect this. And httpd absolutely does do this. *Alias* does not do it, because it is not their job. They are *not* designed to protect content, they simply map a *url* to the filesystem. But why is there the Directive ScriptAlias? -- This Directive should then better be removed. It could easily be removed. It is a convenience directive for the special case where you *both* want to map a URL, and mark the matching requests as being for cgi scripts. As I have pointed out, it should only be used when you want to do both of those things. It is really silly to be arguing over the security implications of using a directive in a way that is obviously counter to its intentions. Should I be able to use Redirect as a substitute for Deny? Should I be able to use Location as a substitute for Directory? Not every directive is safe to use for every possible purpose. -- Why is it allowed (or without a warning) to make an Alias, where the target is already accessible via another Alias? The problem is not using an alias for an already accessible area. The problem is using an alias to protect content (in this case, the source code of cgi scripts). Ok. Then we can say: For some other reasons, it's not safe to make a ScriptAlias inside DirectoryRoot on *nix (it only looks as if it's safe). Yes, this is true. *Alias* do not do the canonicalization necessary to assure they can't be bypassed. That applies to any filesystem. The docs do make it clear in other places that the only safe way to protect content in the filesystem is using Directory. Joshua.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On 8/20/06, Guy Hulbert [EMAIL PROTECTED] wrote: On Sun, 2006-20-08 at 08:36 -0400, Joshua Slive wrote: But why is there the Directive ScriptAlias? -- This Directive should then better be removed. It could easily be removed. It is a convenience directive for the Not if you don't want to annoy your users ... I meant in the sense that if you were designing the config system today, you could easily omit ScriptAlias. I'm not suggesting it be removed. Joshua.
Re: [PATCH 40026] ServerTokens Off
On 8/20/06, Lars Eilebrecht [EMAIL PROTECTED] wrote: For offering such an option with Apache I've only seen two arguments: 1. Making the server more secure by not revealing any (or fake) server information. 2. Saving bandwidth. 3. Make all the crazy people go away. There may be no valid reason for it, but we're sick of hearing about it so just give it to them so we can get back to real work. As I've said, I don't have a strong opinion in either direction. Joshua.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On 8/19/06, Carsten Wiedmann [EMAIL PROTECTED] wrote: Why is it really bad to have a ScriptAlias inside the DocumentRoot? It's only another file system location. And it's only one line in the config file instead of four. You have only a problem because of the unexpected behavior of httpd with case-insensitive/case-preserved file systems ;-) And on Windows, the simplest way to make a consistent behavior with URI's is to have a alias match case-insensitive. You seemed to miss the second part of my message, where I pointed out that there are multiple ways to skip around aliases if they point to directories that are otherwise accessible from the filesystem. For example, a request for //cgi-bin/file.cgi might work (I haven't tested it) or using one of the other funny characteristics of the windows filesystem that make multiple URLs point to the same filesystem location. That is why if you want to restrict access to a filesystem location, you need to use Directory, which knows about all these funny things. Joshua.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On 8/19/06, Carsten Wiedmann [EMAIL PROTECTED] wrote: [I don't agree with large chunks of what you wrote, but the crux of the matter is here:] And why are sometimes (part of) the URI is case-sensitive and somtimes not and what happens in consequence because of this behavior. And this behavior is the only reason why it can be (on some systems) a problem to have the ScriptAlias inside the DirectoryRoot. That last sentence is simply not true. Search the the bugtraq archives for all the other vulnerabilities in windows web servers caused by subtleties of the filesystem. It is not the job of *Alias* to deal with that; the *Alias* directives map a URL to the filesystem. If you want to protect things in the filesystem, you have Directory. Yes, it would be nice if httpd could force the use of a canonical case on case-insensitive filesystems. It can be partially done with mod_rewrite. But that would not make it safe to use ScriptAlias in the way you want. Joshua.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On 8/18/06, Mark J Cox [EMAIL PROTECTED] wrote: See http://marc.theaimsgroup.com/?l=bugtraqm=115527423727441w=2 which basically reports if you put cgi-bin under docroot then you can view cgi scripts on OS which have case insensitive filesystems Joe replied: http://marc.theaimsgroup.com/?l=bugtraqm=115574424402976w=2 and I submitted that as an DISPUTED to CVE But the original reporter disagrees: http://marc.theaimsgroup.com/?l=bugtraqm=115583509231594w=2 I think the right response here is to make it more explicit in the documentation that putting a ScriptAlias cgi-bin inside document root is bad. Yes, this is a relatively common configuration error. Although this does not make it a bug, it does point out that our documentation could be clearer. Unfortunately, the basic problem is that people see the ScriptAlias in the default config file and assume that is the only way to activate cgi scripts, so regardless of what we put in the docs, it won't help that much. Something like the following should probably be added to the docs for ScriptAlias (and perhaps in the CGI tutorial): notedirectiveScriptAlias/directive is used to strongboth/strong map a URL to a directory strongand/strong mark requests for that URL as pointing to CGI scripts. It should not be used for directories that are already accessible from the web because they are under the directive module=coreDocumentRoot/directive, for example. Instead, you can use: example lt;Directory /usr/local/apache2/htdocs/cgi-dir gt;br / SetHandler cgi-scriptbr / Options ExecCGIbr / lt;/Directorygt; /example/note Joshua.
Re: CGI Script Source Code Disclosure Vulnerability in Apache for Windows
On 8/18/06, Carsten Wiedmann [EMAIL PROTECTED] wrote: Joshua Slive schrieb: On 8/18/06, Mark J Cox [EMAIL PROTECTED] wrote: I think the right response here is to make it more explicit in the documentation that putting a ScriptAlias cgi-bin inside document root is bad. Yes, this is a relatively common configuration error. Although this does not make it a bug, it does point out that our documentation could be clearer. Unfortunately, the basic problem is that people see the ScriptAlias in the default config file and assume that is the only way to activate cgi scripts, so regardless of what we put in the docs, it won't help that much. I don't complete agree with you... IMHO the basic problem is: The URL-path in ScriptAlias (like in Alias and Location) is compared case sensitive first, also on Windows. The normal URI to path translation (directory-path) not on Windows. That should be better explained in the manual. Yes, it should be explained that *Alias* are case-sensitive in their first argument. But your diagnosis is not quite correct. URLs are always case sensitive in httpd (and in the HTTP RFC). The fact that multiple different URLs happen to map to the same filesystem location is an artificat of the filesystem, not of the path translation code. httpd does handle case-insensitivity correctly in its filesystem code (such as the Directory block). BTW: ScriptAlias is not complete the same as an Options ExecCGI. On Windows you can use something like that to avoid the problem: ScriptAliasMatch (?i)^/cgi-bin(.*) /apache/cgi-bin$1 I don't know why you say that Options/SetHandler isn't the same as ScriptAlias. They are identical in all important respects, as far as I know. Your suggestion is not a good one for this problem, because there are other ways to dodge around that regex on many filesystems (multiple slashes, special characters, etc). Those are all handled properly by Directory. (Your suggestion is fine for the general question How do I make the cgi-bin alias case-insensitive? but it is not a safe way to use ScriptAlias to put the cgi-bin inside the DocumentRoot.) Joshua.
Re: [PATCH 40026] ServerTokens Off
On 8/12/06, Eli Marmor [EMAIL PROTECTED] wrote: But if this option is a so strong dream for somebody, the minimum that can be done to help a little, is a strong recommendation against using this option, in the documentation. I'm +1 on the concept for this patch (I haven't reviewed the code). I think that the docs should say something like noteSetting directiveServerTokens/directive to less than codeminimal/code is not recommended because it makes it more difficult to debug interoperational problems./note And my +1 isn't very strong. I have no problem with saying that this small bit of advertising is the tiny price that you pay for using our free software. But just to make this never-ending issue go away, I'd say put it in. Joshua.
Re: Tracking CGI Exec Calls
On 8/11/06, Silvio Mazzaro [EMAIL PROTECTED] wrote: Guy Hulbert wrote: What is the problem you are trying to solve ? I'd like to know who's using sendmail from the Web. This is a hint ... do you want to prevent CGI scripts from calling sendmail ? No, It's important for my users to use sendmail from their applications, but I'd like to control it to avoid spamming problems. I don't think there is anything better than 'strace' (except 'dtrace' on solaris) but I have not tried using either. Perhaps It is possible to track system calls from mod_perl, but I'm still studying it... I'll let you know if I find (or someone on this list) a better solution then 'strace'. I don't know of any way to do this from apache. But you could simply replace sendmail with a script that dumps the relevant info to a log file before passing parameters on to the real sendmail. Joshua.
Re: Tracking CGI Exec Calls
On 8/11/06, Guy Hulbert [EMAIL PROTECTED] wrote: On Fri, 2006-11-08 at 09:47 -0400, Joshua Slive wrote: On 8/11/06, Silvio Mazzaro [EMAIL PROTECTED] wrote: Guy Hulbert wrote: What is the problem you are trying to solve ? I'd like to know who's using sendmail from the Web. snip Perhaps It is possible to track system calls from mod_perl, but I'm still studying it... I'll let you know if I find (or someone on this list) a better solution then 'strace'. I don't know of any way to do this from apache. But you could simply replace sendmail with a script that dumps the relevant info to a log file before passing parameters on to the real sendmail. Actually, the sendmail log should give you that much but all the mail is sent by the user running apache so it would require virtual domains on the mail side which match the vhosts on the apache side to do much good. The script would also have access to the CGI env variables, including precise data on the URL called. But anyway, this whole thread belongs on the users list. Joshua.
Re: svn commit: r427780 - in /httpd/httpd/trunk: docs/manual/mod/mod_authz_core.xml modules/aaa/mod_auth.h modules/aaa/mod_authz_core.c
On 8/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: bnicholes Date: Tue Aug 1 15:54:38 2006 New Revision: 427780 URL: http://svn.apache.org/viewvc?rev=427780view=rev Log: Converted the reject directive to be definitive and enabled directory_merge to merge all of the authorization rules and logic. Can you explain how you do something like the following: Allow access from anywhere except IPs starting 10.2, but also allow access from the specific subnet 10.2.1. Joshua.
Re: svn commit: r424817 - /httpd/httpd/trunk/docs/conf/extra/httpd-dav.conf.in
On 7/23/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: @@ServerRoot@@ doesn't guarantee that either :-/ grrr - please don't start commit wars by reverting without some small post to discuss? Here's the reply I sent to your original commit (msgid [EMAIL PROTECTED]). I didn't receive a response. (But that does remind me that I didn't revert it properly. Need to put back the var part.) I believe the issue here is that exp_runtimedir is writable only by root, while DavLockDB needs to be writable by child processes. I tried to introduce the var directory in the docs as an example of a child-writable directory, and have tried to use it consistently as such. I consider the stuff in conf/extra to be essentially documentation, not necessarily working configurations. Joshua.
Re: svn commit: r410757 - /httpd/httpd/trunk/docs/conf/extra/httpd-info.conf.in
On 6/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Add example/default allow-from for localhost, please??? Location /server-status SetHandler server-status Require host .example.com +Allow from 127 /Location I think you are looking for Require ip 127 or something like that. But I'm not sure why it is necessary. We've always just used .example.com here, haven't we? Joshua.
Re: svn commit: r410758 - /httpd/httpd/trunk/docs/conf/extra/httpd-dav.conf.in
On 6/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ewww... can't we be consistant with our workfiles paths? -DavLockDB @@ServerRoot@@/var/DavLock +DavLockDB @exp_runtimedir@/DavLock I believe the issue here is that exp_runtimedir is writable only by root, while DavLockDB needs to be writable by child processes. I tried to introduce the var directory in the docs as an example of a child-writable directory, and have tried to use it consistently as such. I consider the stuff in conf/extra to be essentially documentation, not necessarily working configurations. Joshua.
Re: svn commit: r410761 - /httpd/httpd/trunk/docs/conf/extra/httpd-mpm.conf.in
On 6/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: wrowe Date: Wed May 31 22:42:13 2006 New Revision: 410761 URL: http://svn.apache.org/viewvc?rev=410761view=rev Log: That's the point, isn't it? All mpm's in one basket? Sure, but windows has its own config file where we left the mpm_winnt stuff in. So putting it here is duplication. Joshua.
Re: Disable multiple file extension support?
On 5/25/06, Rich Bowen [EMAIL PROTECTED] wrote: The folks at Drupal have apparently just discovered that something.php.bar is executed as PHP, and, thus, checking to see if a file ends with .php is not sufficient to ensure that their file upload feature can't be exploited. In fact, they have a whitelist, and check to see the files end only with stuff on the whitelist, so it's a little more robust than that, but still fairly easy to get around. I've been asked to pass on a request for a configuration directive to disable the support for multiple file extensions - that is, ensure that only the final file extension is honored when determining how to handle a file. I haven't thought though all the implications of such a directive, nor do I know how feasible it is. But I've passed on the request. You can pass back FilesMatch \.php$ SetHandler php-script /FilesMatch (in place of any other method of activating php) Yes, this confuses many people who aren't used to the fact that a file can have more than one extension. But I believe it is easy enough to deal with when you know about it. Given the existence of FilesMatch, I don't think we really need to add an option to AddHandler/AddType/etc. (I'm trying not to comment about the general wisdom of having a file-upload area that has any kind of dynamic processing enabled in any way...) Joshua.
Re: How do I get PATH_INFO from 2.0
On 5/18/06, pradeep kumar [EMAIL PROTECTED] wrote: Hi, Is there any other way of getting PATH_INFO without using mod_include? More details please. PATH_INFO works find in 2.x. Perhaps you need to look at the AllowPathInfo directive. Joshua.
Re: changing request priority in Apache2.2
On 5/10/06, Tiago Semprebom [EMAIL PROTECTED] wrote: Hello, I'm developing a new handler module in apache, in this module I need to do some changes in the incoming requests, like change the request priority, for example: I need to intercept the request and in some away to change or set a priority to change the service priority of this request so that when this request is attended by the content generator (when this request is going to be attended by a thread/process of the server) this request is attended in accordance with his priority. Tiago, you've asked this same question (with slight variations) several times on the users list. At least once you got some interesting responses, but never followed up. Posting the question again to a forum where it is not on topic is not a good way to proceed. So I suggest: 1. Following up on [EMAIL PROTECTED] to the responses you got. 2. Try the modules developers list where this would be on topic: http://modules.apache.org/subscribe In either case, you're going to need to provide alot more detail about what you are trying to do and why. For example, what is the content generator and on what basis do you want to set the priority. Joshua.
Re: Laying undead myths to rest
On 5/8/06, Joseph Dane [EMAIL PROTECTED] wrote: Joshua Slive [EMAIL PROTECTED] writes: In very early versions of the Apache HTTP Server, the directiveAddType/directive directive was also used to activate special server-side processing (such as modulemod_include/module or PHP) by assigning magic MIME types to files. This can create problems in more recent versions and should be avoided in favor of using the directiveAddHandler/directive directive./note for the record (not necessarily for the docs) can you expand on the sort of problems that might arise? Essentially, any processing that depends on the Content-Type will be messed up because a fake Content-Type is being used to trigger other processing. For example, people using multiviews with php often have problems: http://tranchant.plus.com/notes/multiviews (Lots of these content-type-dependent things are semi-broken anyways because content-type can be changed very late in processing, messing up decisions based on the configured type.) Joshua.
Re: apr_brigade_insert_file() LFS/Linux issues
On 5/3/06, Joe Orton [EMAIL PROTECTED] wrote: On Wed, May 03, 2006 at 02:39:33PM +0200, Niklas Edmundsson wrote: I've run into apr_brigade_insert_file() creating brigades that's not possible to sendfile() (EINVAL), this is with httpd-2.2.2 on Ubuntu Breezy Linux amd64 (64bit). The file in question is 4.3GB, and it seems that sendfile() doesn't cope with that. Has anyone else seen this? No, works fine here. Can you get strace output for the failing call? Just a random note: There was a report of a problem with 2.2.2 and mod_include on the users list that went away when sendfile was turned off. Sounds similar. Joshua.
Re: Email address on mail archive (fwd)
On 4/28/06, Justin Erenkrantz [EMAIL PROTECTED] wrote: On 4/27/06, Joshua Slive [EMAIL PROTECTED] wrote: I know there are people who still hold the idealistic view that we shouldn't be obscuring email addresses at all. Although I agree in principle, I think the world has passed that view by. I think that obfuscation is completely pointless. You're posting to a *public* mailing list. If you can't understand that, well, I just don't care about people who whine. The *only* solution that is valid is to use anti-spam tools on your end. I have no desire to get into a never-ending arms race with spammers. We can't win that battle on those terms. -- justin As I said, I'd love to agree with you. But why don't you try asking 100 random subscribers to our users lists or 100 random bug submitters whether they think it is obvious that their email address will be made public. A couple years ago, they might have agreed. Now, I'd guess the majority wouldn't think that is obvious at all. Joshua.
Fwd: Email address on mail archive (fwd)
This type of request is becoming more and more common. Although mod_mbox obscures the basic to and from address, there are still two problems: 1. It doesn't obscure email addresses in the body of the message (which could be from forwarded/quoted messages). 2. The raw link still gives access to the unobscured addresses. I know there are people who still hold the idealistic view that we shouldn't be obscuring email addresses at all. Although I agree in principle, I think the world has passed that view by. I don't know if anyone is interested in fixing this stuff, but I thought I would at least point out the recurring issue to the mod_mbox developers. Joshua. -- Forwarded message -- From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Apr 27, 2006 7:49 AM Subject: Email address on mail archive (fwd) To: [EMAIL PROTECTED] Sorry -- I can't recall -- what's the policy on this kind of request? --j. --- Forwarded Message Date:Tue, 25 Apr 2006 08:21:17 +0100 From:Jens Finke jens bluegecko.org To: [EMAIL PROTECTED] Subject: Email address on mail archive Hi, I posted a bug report to spamassassin.dev in November 2004. Rather ironically, I notice that my email address has been visible on the mail-archives.apache.org website ever since. Much as I appreciate Spam Assassin, having my primary addr ess accessible to any web trawling spambot rather defeats the whole point. So, could you please delete the address (jens bluegecko.org) from the following four pages: http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200411.mbox/%3C200411 [EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200411.mbox/raw/%3c20 [EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200411.mbox/%3C200411 [EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200411.mbox/raw/%3c20 [EMAIL PROTECTED] Many thanks, Jens Finke -- http://www.bluegecko.org - Traditional Music and Cultures of Kenya - Chasing the Lizard's Tail: across the Sahara by bicycle Mjinga akierevuka mwerevu yupo mashakani When a fool becomes enlightened, the wise man is in trouble --- End of Forwarded Message
Re: 304 response handling with Apache 2.0.53
On 4/24/06, Swapan Gupta [EMAIL PROTECTED] wrote: Hi, I am using Apache 2.0.53. I am observing that when a 304 Not Modified response is returned accompanied by the Location header, the Location does not reach the user. I could see that this header is not mentioned in the RFC for 304 response. However, IIS does send this header back to the user along with the 304. So, I wanted to check if Apache does some special handling restricting this Response header to be passed back to the user? Is this a problem with Apache 2.0.53? If yes, has it been addressed in any of the future Apache versions? Looking forward to your response. I'm not sure what you are trying to do, but RFC 2616 Section 10.3.5 is pretty clear that only certain headers should be sent in a 304, and Location isn't one of them. Joshua.
Re: copyright notices
On 4/21/06, Roy T. Fielding [EMAIL PROTECTED] wrote: I don't know of any reason to hurry a 2.0.x release (heck, I don't know of any reason to continue its development), but I also don't think releasing one with modified copyright years is any more or less legal than continuing to distribute the previous releases. Nor do I think any of our users will ever care enough to challenge the notices. +1
Re: HTTP_X_FORWARDED_FOR in mod_proxy
On 4/20/06, Matthias Behrens [EMAIL PROTECTED] wrote: thx doesnt seem to work on 2.0 its a 2.2 feature isnt it? The early option, which may be necessary here, is a 2.2 feature. Joshua.
Re: HTTP_X_FORWARDED_FOR in mod_proxy
On 4/18/06, Matthias Behrens [EMAIL PROTECTED] wrote: hi is there a way to overwrite the HTTP_X_FORWARDED_FOR instead of adding to it? the problem is that the content of this headerline is sometimes totally chaotic so its very difficult to parse. other possible solutions would be: - to clear the HTTP_X_FORWARDED_FOR before processing the request. (dont know how to do) or - using a different header / env.variable to protokoll the original ipaddress (dont know how to do it eather) The RequestHeader directive, with or without the early option, may be able to clear the old X-Forwarded-For header. Otherwise, you'll need to edit the mod_proxy_http source to change the name of the header. Joshua.
Re: Protecting a file with a password
On 3/6/06, Graham Leggett [EMAIL PROTECTED] wrote: Hi all, I have just tried to convince httpd v2.2.0 to password protect a single file on the filesystem, but without any success. Does anybody know whether this is possible? I tried Location /cgi-bin/dir/file.cgi and Files /full/path/to/cgi-bin/dir/file.cgi The first one should work. The last one won't. The recommended config is something like Directory /full/path/to/cgi-bin/dir/ Files file.cgi ... /Files /Directory We should really give an error if you try to use a slash in a Files statement. Joshua.
Re: Integration Apache2.0.48 and an existing server
On 2/25/06, Arshad Ahamad [EMAIL PROTECTED] wrote: Hello all, I have configure Apache-2.0.48 successfully.Now I would like to integrate Apache-2.0.48 and existing server. So I am unable to start this work ,I am too much confused either Apache embedded into the existing server OR existing serve embedded into the Apache Or other way But in these cases this is realy a difficult work. so any one can suggest me what I do for that, whith some hint. You need to much better define what you mean by existing server. And it is really silly to be starting a new project with 2.0.48. That version is way out of date. Joshua.
Re: how does this get changed?
On 2/17/06, Joost de Heer [EMAIL PROTECTED] wrote: 'Breaking a config file' is IMO that you can't just copy your 2.0 config file and it works. And the new mod_auth(n|z) structure just did that: A 2.0 config file needed changes to work in 2.2. Only if you are using dynamically loaded modules. It works fine except for LoadModule lines. Joshua.
Re: how does this get changed?
On 2/16/06, David Reid [EMAIL PROTECTED] wrote: Rather than try and piece it together, can someone simply answer this simple question? Maybe then this mail and your reply will help other poor souls trying to make the change. Convert this Order deny,allow Deny from all Require all denied But David, you should really just be including mod_access_compat. I think there are plenty of people here who are going to vote against any release of 2.4 unless configurations like the one above work out of the box with mod_access_compat included. So if you are having problems, it is better to identify them now. Joshua.
Re: how does this get changed?
On 2/16/06, Graham Leggett [EMAIL PROTECTED] wrote: Ian Holsman wrote: maybe if mod_access_compat is included by default statically into httpd itself? (unless explicitly disabled) we could make it optional in 2.6 (and remove docs on it), and remove in 2.8 or something. this will give people plenty of time to switch over. This definitely makes sense, +1. Uhh... Please don't remove docs on something that is still in the server. And it should be removed at 3.0. We shouldn't be breaking config files in minor releases. Joshua.
Re: Change in how to configure authorization
On 2/10/06, David Reid [EMAIL PROTECTED] wrote: Joshua Slive wrote: On 1/26/06, Ian Holsman [EMAIL PROTECTED] wrote: Hi Joshua: httpd.conf.in has the new structure httpd-std.conf (the one I was looking at) didn't ;( Hmmm... httpd-std.conf doesn't exist in trunk. Just ran into this and couldn't quite believe what I was seeing. I have a similar config on a server and basically unless you're very careful you end up shutting people out! This change in auth seems to make no sense to me. It's adding a lot of complexity to config files. Do we really need to make this change? Really? At the very least can someone please document how config files need to be changed... And no, I don't think having it in a sample config file is enough. No argument on any of that. But the idea is that if you include mod_access_compat, it should be config-file-compatible with older versions. If that isn't true, you should provide details. Joshua.
mod_mbox cores on ajax
I hadn't checked in a while, but there seem to be lots of mod_mbox cores on ajax again. Here's one backtrace: #0 mbox_cte_escape_html (p=0x60343ca8, s=0x602f5a68 --_=_NextPart_001_01C3C08D.F854E1E0\nContent-Type: text/html;Content-Transfer-Encoding: quoted-printable\n\nhtml xmlns:o=3D\urn:schemas-microsoft-com:office:office\ =\nxmlns:w=3D\urn:schemas-microsof..., len=18446744073709551614, body=0x606f0f88) at mod_mbox_cte.c:82 #1 0x21025620 in mbox_mime_get_body (p=0x60343ca8, m=0x606f0f88) at mod_mbox_mime.c:331 #2 0x21021520 in mbox_static_message (r=0x60343d18, f=0x603590a8) at mod_mbox_out.c:1186 #3 0x2101cbc0 in mbox_file_handler (r=0x60343d18) at mod_mbox_file.c:241 #4 0x4004cff0 in ap_run_handler (r=0x60343d18) at config.c:158
