Re: Style rule change?
On Sun, Jan 8, 2012 at 23:29, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/8/2012 12:04 PM, Guenter Knauf wrote: on the other side: I've asked me already often if we shouldnt increase the maxchar/line; I believe that would in many cases greatly increase readability ... and honestly: who the heck does nowadays work on a 80-line terminal?? Frequently on unix and windows. I haven't yet committed the time to try working on a headless windows server 2008, however :) My text editor windows all default to 81 cols to avoid just this issue. isn't that a relic inherited from stone-time? I would be fine with f.e. 110 or 120 chars/line. Is a limit even appropriate anymore? On what basis? 132 chars is one standard that could be applied. Perhaps a precommit filter to avoid issues in the future? I can nicely fit 3 editor windows at 80 columns on my screen. It's very handy. -- Sent from my toaster.
Re: Error codes
On Wed, Nov 30, 2011 at 01:09, Stefan Fritsch s...@sfritsch.de wrote: On Wednesday 30 November 2011, Guenter Knauf wrote: Am 30.11.2011 01:51, schrieb William A. Rowe Jr.: On 11/29/2011 5:30 PM, Stefan Fritsch wrote: Currently my scripts produces: http://people.apache.org/~sf/error-msg-numbers.diff http://people.apache.org/~sf/error-msg-numbers.list This is level info and up, but that is easily changed. Everything from debug level up should be coded. Suggestion, should we allocate numeric ranges per-file, core vs add-on module, so that there is room for expansion? I am not sure that this is necessary. The error log lines already contain the module name or core. Actually I currently have two scripts, one that tries to identify where to add a number and adds AH, and another one that takes each AH and replaces it with the next free number. So programmers would only need to add AH and run the second script over the source file. The only disadvantage may be that in a list sorted by log number, messages by the same module would not appear next to each other. On the other hand, it should be easy to extend the script to also create a list sorted by module or source file name if that is useful. another suggestion - perhaps add a 3rd char: AHC - core AHM - module then we would have for both core and modules the whole range of error codes ... Sometimes we move code from the core to a module or vice versa. If the code is mostly unchanged, I would want to keep the error message number in this case. So best not encode that in the number, IMHO. If we ever hit the codes, we could either switch to hex or add another digit. Or would it be better to use 5 digits right away? Another thought: Would having the AH0815 numbers verbatim in the source actually hurt search engine users because they get hits on svn.apache.org, github, and whatever. Maybe a macro that hides the actual form would be better? #define APLOGNO(n) AH #n should do the trick. The source would then contain ap_log_error(..., APLOGNO(0815) foo went wrong, ...); which would not produce a hit for AH0815. Thoughts? Any reason *not* to use 5 digits? -- Sent from my toaster.
Re: mod_lua Filter Hook?
On Wed, Jun 15, 2011 at 15:34, Joachim Zobel jzo...@heute-morgen.de wrote: On Wed, 2011-06-15 at 17:04 -0400, Akins, Brian wrote: For filters, etc, not sure we really need buckets in Lua. Maybe just represent them as a table of buffers or something simple like that. This misses my (admittedly not so important) use case of sax buckets. See http://www.heute-morgen.de/site/03_Web_Tech/50_Building_an_Apache_XML_Rewriting_Stack.shtml Sincerely, Joachim I'd been looking forward to mod_lua for a while now expecting it to work similarly to PHP (handle requests, send output without having to worry about how the httpd works). Is that not the case? -- Sent from my toaster.
Re: a plan mod_lua and 2.4
On Sat, Mar 19, 2011 at 04:57, Dan Poirier poir...@pobox.com wrote: On Tue. 2011-03-15 at 09:08 AM EDT, Akins, Brian brian.ak...@turner.com wrote: How many people actual run mod_lua (or a derivative/relative) in production? Am I the only one on a real site? I guess the others, if any, aren't reading dev@. And searching gmane's archive of the user list only turns up a few mentions in almost 90,000 posts. Of course, it's not in a production release of the server yet. And even when 2.4.0 ships, it'll probably still be marked experimental. Actually, I wanted to try it a while ago, but couldn't find any place to actually obtain it on the Apache website... . The documentation was also pretty sparse last I saw, which is another barrier to entry. -- Sent from my toaster.
Re: a plan mod_lua and 2.4
On Tue, Mar 15, 2011 at 07:08, Akins, Brian brian.ak...@turner.com wrote: On 3/14/11 7:51 PM, Brian McCallister bri...@skife.org wrote: I think the right path for this is to shrink the core mod_lua module to be the *minimal* set for integration, and pull all the higher level functionality into a non-core module, which uses the core mod_lua to hook into the server. +1 How many people actual run mod_lua (or a derivative/relative) in production? Am I the only one on a real site? FWIW, moving more and more of the code into Lua and having only very thin wrappers in C is a good idea as well. Plays really nicely with luajit, as well. -- Brian Akins I've been eagerly looking forward to a stable mod_lua with which to make my sites. If done well, Lua could replace PHP as the #1 web scripting language, especially if it avoided making the same mistakes (e.g. dumping everything into the global namespace with no consistent naming or parameter schemes). -- Sent from my toaster.
Re: a plan mod_lua and 2.4
On Tue, Mar 15, 2011 at 08:05, Dan Poirier poir...@pobox.com wrote:
On Tue. 2011-03-15 at 09:36 AM EDT, HyperHacker hyperhac...@gmail.com wrote:
I've been eagerly looking forward to a stable mod_lua with which to
make my sites. If done well, Lua could replace PHP as the #1 web
scripting language
Maybe if people could embed lua in web pages.
Mm, personally I dislike the embed code in HTML thing, as I'm one of
those purists who likes to keep code, presentation, and data separate.
However I did, just for fun, write a web server in Lua which had that
capability. It basically just did a gsub on the HTML file being sent:
str = str:gsub('%?lua%s.-%s%?',
function(code)
local func = loadstring(code:sub(7, -4))
setfenv(func, self.Request.Environment)
return tostring(func())
end)
This is one of the things I love about Lua - once you have the
language, whatever additional functionality you want can be
implemented pretty easily. Little is built in. I imagine you could
work this into your mod_lua configuration fairly easily, and there you
go, code embedded within pages.
--
Sent from my toaster.
Re: rational behind not checking the return value of apr_palloc and apr_pcalloc
On Fri, Sep 3, 2010 at 03:49, Graham Leggett minf...@sharp.fm wrote: On 03 Sep 2010, at 5:31 AM, dave b wrote: Sure ok :) You have no complains from me really here. Just this could be an issue on some platform with some mods potentially :) In order to understand why it isn't an issue for httpd, you need to understand how httpd works. httpd has a thin parent process, which is responsible for spawning children as required to do the actual work. Those children doing the actual work are expendable, and if the child process dies for any reason, the parent process will spawn new child processes to replace them. This is the fundamental reason why it is so difficult to crash an httpd server, because your module code only has the power to crash one child process. If a single child process goes bananas and tries to allocate all the RAM, that child will be terminated and replaced. I only asked this list because the mod_wsgi guy wasn't checking the result of memory allocation. The rational as I see it is: there is only a few cases where this can happen 1: and 2: first the attacker has to find a way to reduce system memory to an almost oom condition by the looks of it. If the attacker has found a way to create an OOM condition, that child process will terminate and be replaced, and the attacker would have caused no lasting damage. Regards, Graham -- ...assuming he attacks a single httpd thread, as opposed to say a distributed attack or attack on an unrelated process. -- Sent from my toaster.
Re: rational behind not checking the return value of apr_palloc and apr_pcalloc
On Fri, Sep 3, 2010 at 07:12, Graham Leggett minf...@sharp.fm wrote: On 03 Sep 2010, at 2:37 PM, HyperHacker wrote: ...assuming he attacks a single httpd thread, as opposed to say a distributed attack or attack on an unrelated process. How would a distributed attack be different? Obviously an attack on an unrelated process would have nothing to do with checking the return value of apr_pcalloc(). Regards, Graham -- first the attacker has to find a way to reduce system memory to an almost oom condition Say, by attacking several httpd threads and/or unrelated processes to get them to eat up memory. -- Sent from my toaster.
Re: rational behind not checking the return value of apr_palloc and apr_pcalloc
On Fri, Sep 3, 2010 at 13:24, dave b db.pub.m...@gmail.com wrote: first the attacker has to find a way to reduce system memory to an almost oom condition Say, by attacking several httpd threads and/or unrelated processes to get them to eat up memory. -- Sent from my toaster. If you know something why not share it ;) ? imho Apache is pretty good - so perhaps you could find a commonly used module that leaks memory? Also, I hope your toaster is running netbsd with apache ^^ -- As flies to wanton boys are we to the gods; they kill us for their sport. -- Shakespeare, King Lear Just tossing around ideas. What's the threshold for killing these child processes? What prevents someone from bringing several to just below that threshold? -- Sent from my toaster.
Re: C as config
On Tue, Jun 8, 2010 at 09:34, Akins, Brian brian.ak...@turner.com wrote: On 6/8/10 8:07 AM, Dan Poirier poir...@pobox.com wrote: That's a shame. I wonder if another embedded language would do better? E.g. mod_perl, mod_python? They've both been around for a while. I wonder why neither has gotten into the server? Lua is leaps and bounds faster than both of those in my experience. -- Brian Akins Perhaps LuaJIT would make it faster still? -- Sent from my toaster.
Re: Fast by default
On Tue, Jun 1, 2010 at 16:25, Sergey Chernyshev sergey.chernys...@gmail.com wrote: This sounds scary! How do large companies enable gzip then? How many hoops do they jump through? sounds like those hoops are in thousands! And I don't understand how one company's setup would be different from another still, even if situation is that bad as you describe it. What kind of trade-offs do large companies go for when they enable gzip? more overall traffic? no cache? Sergey On Tue, Jun 1, 2010 at 6:17 PM, toki...@aol.com wrote: There is zero reason for us to avoid putting deflate into the default configuration. Sorry. There ARE (good) reasons to avoid doing so. I'm the one who wrote the FIRST mod_gzip module for Apache 1.x series so you would think I'd be a strong advocate of 'auto-enablement' by default, but I am NOT. There is HOMEWORK involved here and most users will get into deep tapioca unless they understand all the (ongoing) issues. it is also very arguable that we should leave it off. Yes, it is. I think others have argued well to enable it by default. Disagree. I haven't seen the 'good' argument for 'auto-enablement' yet. Some of the reasons to NOT 'go there' are coming out in other similar threads right now... Here's a clip from the (concurrent) message thread entitled... 'Canned deflate conf in manual - time to drop the NS4/Vary' [snip] Don't forget the ongoing issue that if you ONLY vary on 'Accept-Encoding' then almost ALL browsers will then refuse to cache a response entity LOCALLY and the pain factor moves directly to the Proxy/Content Server(s). If you vary on 'User-Agent' ( No longer reasonable because of the abuse of that header 'out there'? ) then the browsers WILL cache responses locally and the pain is reduced at the Proxy/Content server level, but pie is not free at a truck stop and there are then OTHER issues to deal with. The OTHER 'ongoing issue' regarding compression is that, to this day, it still ONLY works for a limited set of MIME types. The 'Accept-Encoding: gzip,deflate' header coming from ALL major browser is still mostly a LIE. It would seem to indicate that the MIME type doesn't matter and it will 'decode' for ANY MIME type but nothing could be further from the truth. There is no browser on the planet that will 'Accept-Encoding' for ANY/ALL mime type(s). If you are going to turn compression ON by default, without the user having to make any decisions for their particular environment, then part of the decision for the default config has to be 'Which MIME types?' text/plain and/or text/html only? SOME browsers can 'Accept-Encoding' on the ever-increasing .js Javascript backloads but some CANNOT. These 2 issues alone are probably enough to justify keeping compression OFF by default. A lot of people that use Apache won't even be able to get their heads around either one of these 'issues' and they really SHOULD do a little homework before turning it ON. Someone already quoted that... 'people expect the default config to just WORK without major issues'. That's exactly what you have now. It's not 'broken'. Why change it? Kevin Kiley [snip] -Original Message- From: Greg Stein gst...@gmail.com To: dev@httpd.apache.org Sent: Tue, Jun 1, 2010 7:40 am Subject: Re: Fast by default Geez, Eric. No wonder people don't want to contribute to httpd, when they run into an attitude like yours. That dismissiveness makes me embarressed for our community. There is zero reason for us to avoid putting deflate into the default configuration. It is also very arguable that we should leave it off. I think others have argued well to enable it by default, while you've simply dismissed them with your holier-than-thou attitude and lack of any solid rationale. -g On May 31, 2010 8:06 PM, Eric Covener cove...@gmail.com wrote: On Mon, May 31, 2010 at 8:30 PM, Bryan McQuade bmcqu...@google.com wrote: I propose providing an... An additional httpd.conf doesn't sound valuable to me. What slice of non-savvy users would scrutinize an alternate config file, can replace the config file of their webserver, isn't using a webserver packaged by their OS, and wouldn't have just gotten the same information today from the manual and 400,000 other websites? There's currently no ifModule bloat in the default conf, but you're welcome to submit a patch that adds one for deflate or expires (latter seems more unwise to me). See the supplemental configuration section of the generated config. This doesn't address mass-vhost companies failing to allow deflate because it's not in the no-args HTTPD ./configure , which sounds far-fetched to me. I can't recall a users@ or #httpd user implying being subjected to such a thing with their own build or with cheap hosting. -- Eric Covener cove...@gmail.com You seem to think large corporations are competent at web design/administration. -- Sent
Re: Is this possible ?
On Thu, May 20, 2010 at 08:23, exp...@hope.cz wrote: Let’s suppose this configuration |Server1| - |Server2| - |Client| A client sends a request that starts a script on Server2.The script ( running on server2) will download a webpage from Server1. Is it possible to record Client’s IP on Server1, instead of Server2’s IP? In other words, Server1 will think the request for downloading is directly from Client. That is Server2’s IP will be “invisible” for Server1 (Server1 and Server 2 are Apache servers) Is this possbile? Thanks J. Generally, no. Server1 needs to know whom to send the response to. There may be cases where you can transparently pass an entire packet on and do some magic to make things work as if the client connected to Server1 directly, but that's not something a web server would usually be doing. Now, you can pass the client's IP along with the X-Forwarded-For header or similar method, but then you have to be careful. A client could spoof his address by inserting his own X-Forwarded-For (but some proxy servers also legitimately use this header). If clients are able to connect directly to Server1 (even if you don't give out the address), then you'll want to use a more secure method of exchanging the information. -- Sent from my toaster.
Re: Reducing number of mod_lua hook directives
On Tue, May 11, 2010 at 06:52, Dan Poirier poir...@pobox.com wrote:
On 2010-05-10 at 16:03, William A. Rowe Jr. wr...@rowe-clan.net wrote:
On 5/10/2010 2:25 PM, Brian McCallister wrote:
...
to
LuaHook AccessChecker /path/to/script.lua funcname
LuaHook AuthChecker /path/to/script.lua funcname
LuaHook CheckUserID /path/to/script.lua funcname
Any reason not to name the func before the script, especially since path
names
can get long winded, and I'm thinking C like decl funcname(args) {script}
So we'd have
LuaHook AccessChecker funcname /path/to/script.lua
and (unchanged)
LuaHook AccessChecker funcname
which makes the two forms more consistent too. Sounds fine to me.
Dan
+1. Really looking forward to Lua as a web server language.
--
Sent from my toaster.
Re: Reducing number of mod_lua hook directives
On Tue, May 11, 2010 at 08:47, Dan Poirier poir...@pobox.com wrote:
On 2010-05-11 at 08:52, Dan Poirier poir...@pobox.com wrote:
On 2010-05-10 at 16:03, William A. Rowe Jr. wr...@rowe-clan.net wrote:
On 5/10/2010 2:25 PM, Brian McCallister wrote:
...
to
LuaHook AccessChecker /path/to/script.lua funcname
LuaHook AuthChecker /path/to/script.lua funcname
LuaHook CheckUserID /path/to/script.lua funcname
Any reason not to name the func before the script, especially since path
names
can get long winded, and I'm thinking C like decl funcname(args) {script}
So we'd have
LuaHook AccessChecker funcname /path/to/script.lua
LuaHook AccessChecker funcname
I just thought of a problem - right now, the funcname is optional
(defaults to handle). I hate having optional arguments that don't
come at the end. I'd just as soon make it a required argument, but if
people would rather it stay optional, then I'd rather leave it at the
end. What do folks prefer?
Dan
I'd go for making it required, but is there a reason you have to
specify a function? Lua scripts usually start executing from the first
line in the file. It seems to me to make more sense to do that if a
function is not specified (or is - if it's a required argument).
--
Sent from my toaster.
Re: Reducing number of mod_lua hook directives
On Tue, May 11, 2010 at 20:12, Dan Poirier poir...@pobox.com wrote: On 2010-05-11 at 12:55, HyperHacker hyperhac...@gmail.com wrote: On Tue, May 11, 2010 at 08:47, Dan Poirier poir...@pobox.com wrote: I just thought of a problem - right now, the funcname is optional (defaults to handle). I hate having optional arguments that don't come at the end. I'd just as soon make it a required argument, but if people would rather it stay optional, then I'd rather leave it at the end. What do folks prefer? I'd go for making it required, but is there a reason you have to specify a function? Lua scripts usually start executing from the first line in the file. It seems to me to make more sense to do that if a function is not specified (or is - if it's a required argument). The request object is passed to the function as an argument, so there would have to be some other way to give the Lua code access to the request. Say, the global variable Request or Server.Request? -- Sent from my toaster.
Re: slowloris mitigation
I haven't used it, but if mod_reqtimeout makes it entirely redundant, my vote would be to keep it in trunk only. People interested in how the attack/defence work can look at it, and there might be those who for some reason don't want mod_reqtimeout. -- Sent from my toaster.
Re: svn commit: r925858 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS docs/manual/mod/core.xml server/config.c
On Sun, Mar 21, 2010 at 14:28, William A. Rowe Jr. wr...@apache.org wrote: On 3/21/2010 3:14 PM, William A. Rowe Jr. wrote: Include conf/empty/* Include conf/*/whoops.conf The last one (based on an existing conf/empty directive) fails, alerting the admin to the fact that they made a typo, which is good. What I meant to point out was that if conf/empty directory doesn't exist, the first one fails. If conf/empty is then created but left empty, the server starts without so much as a warning. Even Include conf/extra.conf works, where extra.conf isn't a file but an empty directory. Think of all the ways the user can confuse themselves with this new feature. The former seems like correct behaviour: it's including all files in the directory, which is none. You might want to be able to move files in an out of that directory for convenience. The latter does seem like a bug - specifying a directory without a /* should trigger a warning.
What happened to mod_lua?
A while back I had the idea that Lua would be a great scripting language for web servers. I checked Google, and several pages mentioned a recently developed Apache httpd module that does just that. However, even months later, all a search finds is a couple blogs and sites talking about the next version, many 404s, and a little discussion about the history/future of this module and how cool it's going to be. There are a few different home pages and official trackers which were last updated years ago; broken, run-down ghost towns of sites. Nothing on Apache's site at all. My question is, where is it? What's happened? I wanted to get involved in its development, but I can't find it! Only these old run-down sites hosting 3-year-old Win32 binaries. Has the project been abandoned? -- Sent from my toaster.
