RE: why not post mod_gzip 2.0? (was: Re: [PATCH] Add mod_gz to httpd-2.0)
The absolute best way to stay on top of API changes is to make your code available to the people making those changes. Rasmus... We don't want any distractions to the core code until it's stable. It took 5-6 months to get mod_gzip stable for 1.3.x. I doubt it will take that long in Apache 2.x but until it's stable why release something which will could cause a problem. Kevin and I have asked that mod_gzip be included in Apache 1.3.x because it's stable, been tested by thousands of users and is part of the spec. We'd like to repeat the same performance for 2.x Peter -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Sent: Friday, September 07, 2001 12:08 AM To: [EMAIL PROTECTED] Subject: RE: why not post mod_gzip 2.0? (was: Re: [PATCH] Add mod_gz to httpd-2.0) Why won't you post mod_gzip 2.0 *today*? Because Apache 2.x is not STABLE, not In BETA and the API set is not yet FROZEN... When it is, we will release mod_gzip as a third party module, which we will support and maintain. I have stayed far away from this thread, but this just doesn't make any sense to me. The absolute best way to stay on top of API changes is to make your code available to the people making those changes. As soon as we had an Apache2 PHP filter it was on our public CVS server and both Doug and Ryan have tweaked it every now and then and many people have tested it and found problems. I don't understand how this could possibly be a bad thing and definitely reduces the amount of tail-chasing we will have to do later on. -Rasmus
re: why not post mod_gzip 2.0? (was: Re: [PATCH] Add mod_gz to httpd-2.0)
You and Kevin never answered my simple question: Why won't you post mod_gzip 2.0 *today*? Kevin, the best way to have mod_gzip in Apache 2.0 is to make it available. You knows i'm using it on Apache 1.3 for many times and be more than happy to see such an excellent works on 2.0 :)
RE: why not post mod_gzip 2.0? (was: Re: [PATCH] Add mod_gz to httpd-2.0)
Why won't you post mod_gzip 2.0 *today*? Because Apache 2.x is not STABLE, not In BETA and the API set is not yet FROZEN... When it is, we will release mod_gzip as a third party module, which we will support and maintain. In the meantime use mod_gz. Peter -Original Message- From: Greg Stein [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 10:34 PM To: [EMAIL PROTECTED] Subject: why not post mod_gzip 2.0? (was: Re: [PATCH] Add mod_gz to httpd-2.0) On Wed, Sep 05, 2001 at 01:46:55PM -0600, Peter J. Cranstone wrote: I suppose the only thing we can do is contribute. Kevin has, mod_gzip was released under an ASF license which was approved by the ASF Board. If there is a hidden agenda there then you're better than I at spotting it. Mod_gzip is available for 1.3.x It will be available for 2.x when you hit beta. ... Now tell me where the hidden agenda is. You and Kevin never answered my simple question: Why won't you post mod_gzip 2.0 *today*? I asked several times, but it never got answered. I seem to recall somebody stating it was being held, pending stability of the internal Apache APIs. But that isn't an issue if it is to be incorporated into Apache. Another response was look at 1.3 and port it forwards to 2.0. Why should that happen, when you've done the work? If you intend to contribute it, then why the delay, making us repeat your work? Without that simple question answered, then yes: I would think there is some kind of hidden agenda. Avoiding that question, and not posting mod_gzip 2.0 makes it appear that you are trying to hide something. The more conspiratorial-minded of us would simply believe this whole thread is to create a division and weaken the voting for mod_gz. Much like politicians will introduce a second, similar bill to confuse and divide supporters and then crush both bills. But of course that wouldn't happen here, now would it? :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
RE: [PATCH] Add mod_gz to httpd-2.0
After 3-4 years we know exactly how you work. Peter -Original Message- From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 11:58 AM To: [EMAIL PROTECTED] Subject: Re: [PATCH] Add mod_gz to httpd-2.0 [EMAIL PROTECTED] wrote: Ian... are you a committer? What do you say about adding ZLIB to Apache source ASAP. Yea or nay? This only demonstrates your non-understanding of how we work, and/or how to work with us. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
Peter J. Cranstone wrote: After 3-4 years we know exactly how you work. Oh? Then what is the explanation for Kevin publicly soliciting an individual to do something that recent discussion has shown the group considers moot? Regardless of facts, it is perception that matters. Not speaking for anyone else, my perception of the practises in which you and Kevin have seemingly engaged makes me personally wary and unwilling to take anything you write at face value. Little things, like Kevin's post just now, and the multiplicity of 'I'm not with RC' mail origins a couple of years ago, and the overall tenor of your posts.. I try very hard to keep an open mind; when I committed to you to get you a session at ApacheCon to talk about generic content compression issue, I meant it -- but was overruled 4 to 1. Despite my best efforts at open-mindedness, something about your collective tactics and polemic keeps making me want to close my mind against you. And I suspect (but do not know) that others have the same perception, which may have been the cause of that 4-1 vote. Most people I take at face value -- but you seem to change positions so much that I feel I cannot but suspect you of having a hidden agenda. Maybe you do not, and maybe you do -- and maybe it is no more than trying to get RC's package into the Apache distribution because of the marketing bulge that would give RC. But.. maybe it is more than that. I cannot tell, and you have not made it easy to tell, and I am not sure I would blindly accept it if you did. This is not technical, this is social and political. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
RE: [PATCH] Add mod_gz to httpd-2.0
I suppose the only thing we can do is contribute. Kevin has, mod_gzip was released under an ASF license which was approved by the ASF Board. If there is a hidden agenda there then you're better than I at spotting it. Mod_gzip is available for 1.3.x It will be available for 2.x when you hit beta. It will contain the same license as before. There are no patents, TM's or anything else associated with it. We will continue to support both versions. Now tell me where the hidden agenda is. If it's not technical, then it's social (you just plain don't like us... Not a problem) or political (the powers that be don't like us... Again not a problem) From a political standpoint I'm pissed that Covalent Technologies can cut a deal with Compaq for the new Compaq Apache server (wonder if it will ship with or without compression (details are tough to find on this whole deal). But you know what, more power to Ryan and his crew for doing something like that. Did I ever see a vote for something like that, no... I even checked the ASF minutes... Nothing since February. Whatever. This whole conversation is mute, include, exclude, revoke whatever, mod_gzip will always be available from Kevin and I and we will support it. If you don't include it, all it means is another click to our website. Later... Peter -Original Message- From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 12:20 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] Add mod_gz to httpd-2.0 Peter J. Cranstone wrote: After 3-4 years we know exactly how you work. Oh? Then what is the explanation for Kevin publicly soliciting an individual to do something that recent discussion has shown the group considers moot? Regardless of facts, it is perception that matters. Not speaking for anyone else, my perception of the practises in which you and Kevin have seemingly engaged makes me personally wary and unwilling to take anything you write at face value. Little things, like Kevin's post just now, and the multiplicity of 'I'm not with RC' mail origins a couple of years ago, and the overall tenor of your posts.. I try very hard to keep an open mind; when I committed to you to get you a session at ApacheCon to talk about generic content compression issue, I meant it -- but was overruled 4 to 1. Despite my best efforts at open-mindedness, something about your collective tactics and polemic keeps making me want to close my mind against you. And I suspect (but do not know) that others have the same perception, which may have been the cause of that 4-1 vote. Most people I take at face value -- but you seem to change positions so much that I feel I cannot but suspect you of having a hidden agenda. Maybe you do not, and maybe you do -- and maybe it is no more than trying to get RC's package into the Apache distribution because of the marketing bulge that would give RC. But.. maybe it is more than that. I cannot tell, and you have not made it easy to tell, and I am not sure I would blindly accept it if you did. This is not technical, this is social and political. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
I really should just ignore this. But oh well From a political standpoint I'm pissed that Covalent Technologies can cut a deal with Compaq for the new Compaq Apache server (wonder if it will ship with or without compression (details are tough to find on this whole deal). But you know what, more power to Ryan and his crew for doing something like that. Did I ever see a vote for something like that, no... I even checked the ASF minutes... Nothing since February. Whatever. a) This is not Ryan and his crew. I am an engineering manager at Covalent. I have 0 control over partnerships and the like. b) Why does this deal piss you off? Covalent and Compaq are partnering to promote the use of Apache and Compaq hardware with Linux in the marketplace. They were looking for an company to partner with to help, and for Apache that was us. c) Right now, the solution does not include compression at all. That may change in the future, but I don't know of any plans along those lines. d) This has nothing to do with the ASF, so the ASF wasn't involved. Covalent sells a version of Apache (with only EAPI patches applied), and proprietary modules. We do not need to check with the ASF to partner with a company that wants our help to do the same basic thing. If RemoteCommunications wants to sell Apache, feel free, you don't need ASF permission to do so. You do need to follow the license, which Covalent does. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] Add mod_gz to httpd-2.0
Okay, I'll bite. On Wed, Sep 05, 2001 at 01:46:55PM -0600, Peter J. Cranstone wrote: [Snip: nothing that hasn't been said in this thread before] If it's not technical, then it's social (you just plain don't like us... Not a problem) or political (the powers that be don't like us... Again not a problem) From a political standpoint I'm pissed that Covalent Technologies can cut a deal with Compaq for the new Compaq Apache server (wonder if it will ship with or without compression (details are tough to find on this whole deal). But you know what, more power to Ryan and his crew for doing something like that. Did I ever see a vote for something like that, no... I even checked the ASF minutes... Nothing since February. Whatever. Why are you dragging this into the discussion? I can't see that it has anything to do with it. Anyone else seeing this as a bad thing for Apache? I don't see why they shouldn't be allowed to do this, anyone should be able to do this, even your company. But do you have the expertise? Looking at the License of Apache it doesn't make it sound like they wouldn't be able to do so, as long as they state like written in the license: This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/). Which I am quite sure they will, Covalent will probably use every chance they get to promote Apache. The reason why there might not be more information on this deal than what Covalents website gives[1] might be that the rest is to be worked out? When I heard this I was kind of happy for Apache, 'cause it can only be a good thing if Covalent gets a deal like this. More money, more likely that Ryan, Randy, Dough, William, etc. will keep up their very good work on Apache. my $cent = 2; [1] http://www.covalent.net/company/press/news-20010828.php -- Thomas Eibner
RE: [PATCH] Add mod_gz to httpd-2.0
Guys, Conversation is over. I have nothing more to add. This whole conversation is degenerating into meaningless nonsense. Someone else can carry the thread. Peter -Original Message- From: Thomas Eibner [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 2:21 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] Add mod_gz to httpd-2.0 Okay, I'll bite. On Wed, Sep 05, 2001 at 01:46:55PM -0600, Peter J. Cranstone wrote: [Snip: nothing that hasn't been said in this thread before] If it's not technical, then it's social (you just plain don't like us... Not a problem) or political (the powers that be don't like us... Again not a problem) From a political standpoint I'm pissed that Covalent Technologies can cut a deal with Compaq for the new Compaq Apache server (wonder if it will ship with or without compression (details are tough to find on this whole deal). But you know what, more power to Ryan and his crew for doing something like that. Did I ever see a vote for something like that, no... I even checked the ASF minutes... Nothing since February. Whatever. Why are you dragging this into the discussion? I can't see that it has anything to do with it. Anyone else seeing this as a bad thing for Apache? I don't see why they shouldn't be allowed to do this, anyone should be able to do this, even your company. But do you have the expertise? Looking at the License of Apache it doesn't make it sound like they wouldn't be able to do so, as long as they state like written in the license: This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/). Which I am quite sure they will, Covalent will probably use every chance they get to promote Apache. The reason why there might not be more information on this deal than what Covalents website gives[1] might be that the rest is to be worked out? When I heard this I was kind of happy for Apache, 'cause it can only be a good thing if Covalent gets a deal like this. More money, more likely that Ryan, Randy, Dough, William, etc. will keep up their very good work on Apache. my $cent = 2; [1] http://www.covalent.net/company/press/news-20010828.php -- Thomas Eibner
Re: [PATCH] Add mod_gz to httpd-2.0
From a political standpoint I'm pissed that Covalent Technologies can cut a deal with Compaq for the new Compaq Apache server (wonder if it will ship with or without compression (details are tough to find on this whole deal). This is news to me, and certainly no permission has been given to either Compaq nor Covalent to call anything a 'Compaq Apache server.' I am on the ASF board and I can tell you this has not come before us. I should point out that AFAIK, Compaq Apache server is not a product name that I have ever heard before. A quick look at Compaq's web site also does not come up with that name anywhere. If somebody does find that name as a product anyplace, please let me know ASAP. However, Covalent knows very well what we can and can not call products, so I can't imagine that we would use that name. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
RE: [PATCH] Add mod_gz to httpd-2.0
If somebody does find that name as a product anyplace, please let me know ASAP. It was on a recent CNET release: http://news.cnet.com/news/0-1003-200-6963955.html Compaq Computer has signed a deal with Covalent Technology to jointly develop and market Covalent's Apache Web server software, the companies plan to announce Monday. -Original Message- From: Ryan Bloom [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 2:27 PM To: [EMAIL PROTECTED]; Rodent of Unusual Size Subject: Re: [PATCH] Add mod_gz to httpd-2.0 From a political standpoint I'm pissed that Covalent Technologies can cut a deal with Compaq for the new Compaq Apache server (wonder if it will ship with or without compression (details are tough to find on this whole deal). This is news to me, and certainly no permission has been given to either Compaq nor Covalent to call anything a 'Compaq Apache server.' I am on the ASF board and I can tell you this has not come before us. I should point out that AFAIK, Compaq Apache server is not a product name that I have ever heard before. A quick look at Compaq's web site also does not come up with that name anywhere. If somebody does find that name as a product anyplace, please let me know ASAP. However, Covalent knows very well what we can and can not call products, so I can't imagine that we would use that name. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] Add mod_gz to httpd-2.0
Peter J. Cranstone wrote: Conversation is over. I have nothing more to add. This whole conversation is degenerating into meaningless nonsense. Someone else can carry the thread. This clever technique of ducking out of the conversation rather than answering pointed questions is just *so* endearing, Peter. And it is one of the tactics to which I alluded earlier as making me wary of your motives. You bring something up, we question you about it, you say the conversation is meaningless. You made remarks, statements, and allegations -- stand up to them. As for 'nothing more to add' -- well, you could add the answers to the questions you have been asked.. But you do have one thing partly right, IMO -- trying to converse with you seems to frequently be an exercise in futility. That is a social issue, and if the rest of the group cannot have a reasonable conversation with a module developer, no technical merit of the module is going to overcome the irritation and frustration the rest of the group is going to experience if it gets included. So, in short, if you have any interest in mod_gzip being included, stop behaving like an ass and *converse*. 'Conversation over,' forsooth! -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
RE: [PATCH] Add mod_gz to httpd-2.0
Ken, Kiss my ass... I have work to do. You want to continue the conversation take it off line you know where I am. Peter -Original Message- From: Rodent of Unusual Size [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 2:42 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] Add mod_gz to httpd-2.0 Peter J. Cranstone wrote: Conversation is over. I have nothing more to add. This whole conversation is degenerating into meaningless nonsense. Someone else can carry the thread. This clever technique of ducking out of the conversation rather than answering pointed questions is just *so* endearing, Peter. And it is one of the tactics to which I alluded earlier as making me wary of your motives. You bring something up, we question you about it, you say the conversation is meaningless. You made remarks, statements, and allegations -- stand up to them. As for 'nothing more to add' -- well, you could add the answers to the questions you have been asked.. But you do have one thing partly right, IMO -- trying to converse with you seems to frequently be an exercise in futility. That is a social issue, and if the rest of the group cannot have a reasonable conversation with a module developer, no technical merit of the module is going to overcome the irritation and frustration the rest of the group is going to experience if it gets included. So, in short, if you have any interest in mod_gzip being included, stop behaving like an ass and *converse*. 'Conversation over,' forsooth! -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
Peter J. Cranstone wrote: It was on a recent CNET release: http://news.cnet.com/news/0-1003-200-6963955.html Compaq Computer has signed a deal with Covalent Technology to jointly develop and market Covalent's Apache Web server software, the companies plan to announce Monday. Thank you for the reference. Yes, that is phrased ambiguously; it can either be taken as Covalent owning Apache, or Covalent's software *for* Apache. I expect Ryan will have someone contact C!NET about it. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
Peter J. Cranstone wrote: Kiss my ass... And now to the invective. I have work to do. Which apparently does not include answering questions about your previous posts. Well, you did answer one of the ones about the 'Compaq Apache Server' thing, so thanks for that. You want to continue the conversation take it off line you know where I am. No, thanks. I have nothing to hide, so I will keep my remarks and responses right here in the public eye. If you have something you want to say privately, you can send to *me* offline, and I will keep it private. You know, you are showing a definite talent for moving me from 'wary' to 'hostile.' -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
In a message dated 01-09-05 14:16:59 EDT, Marc Slemko wrote... This is not technical, this is social and political. Then keep it off the forum... you fucking didactic self-righteous asshole. When was the last fucking time you posted anything useful? Send your 'social and political' commentary to us privately. You know where we are. Yours... Kevin Kiley BTW: Seen the latest press release regarding Covalent and Compaq? Any comments for those boys?
Re: [PATCH] Add mod_gz to httpd-2.0
In a message dated 01-09-05 14:16:59 EDT, Marc wrote... After 3-4 years we know exactly how you work. Oh? Then what is the explanation for Kevin publicly soliciting an individual to do something that recent discussion has shown the group considers moot? I asked him what he 'thought', asshole. Are you seriously telling me you think I can't come onto this PUBLIC forum for a non-profit organization and ask someone what their opinon is? Give me a fucking break. Yours... Kevin Kiley
Re: [PATCH] Add mod_gz to httpd-2.0
In a message dated 01-09-05 16:14:01 EDT, you write: This is news to me, and certainly no permission has been given to either Compaq nor Covalent to call anything a 'Compaq Apache server.' I am on the ASF board and I can tell you this has not come before us. Actually... it's called the 'Covalent Apache Web Server'. There isn't anything in your board meeting minutes that authorizes that, either. Not complaining... just pointing out a fact. I am with Peter on this. More power to them. Randy Terbrush hasn't appeared here for awhile but there is no question he should benefit financially from his early work with Apache. Ryan and Dirk and Harrie and Doug and Daniel and Jon and Bill Wrowe ( others?... Apache contibutors all ) deserve the same. I hope they all get to buy their own private island following the recent Compaq deal the timing of which was perfect since the valuation of the jsut announced Compaq and Hewlett-Packet merger is in the neighborhood of 25 BILLION ( With a B ) dollars. Again... more power to all. Randy and William Rowe alone have busted their ASSES trying to give you 2.0. I hope they both get private jets out of the deal. Later... Kevin Kiley
Re: [PATCH] Add mod_gz to httpd-2.0
[EMAIL PROTECTED] wrote: In a message dated 01-09-05 14:16:59 EDT, Marc Slemko wrote... This is not technical, this is social and political. Then keep it off the forum... you fucking didactic self-righteous asshole. As I said, invective time. As I also said, except to Peter alone, you are showing a definite talent for changing my opinion toward RC from 'wary' to 'hostile.' I guess you are now included.. Sorry to disappoint you, but it *belongs* in this forum. Whether the group as a whole can get along with you, or cannot, is extremely relevant. When was the last fucking time you posted anything useful? 'What have you done for me lately', eh? And the relevance is..? I have been busy with ApacheCon, so I guess I am not entitled to have an opinion on technical matters any more? Or on how the project operates? Send your 'social and political' commentary to us privately. You know where we are. That would be pointless, since I would only be expressing my own opinions and you would be the only ones to tell me I was wrong (if I were, and I may be). Stalemate. Here everyone has a chance to comment. I have been willing to cut you guys slack from the beginning, but that ends now. Get along with the people here, or go away. That is my opinion. BTW: Seen the latest press release regarding Covalent and Compaq? Any comments for those boys? Yep; read my other replies in this thread. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
[EMAIL PROTECTED] wrote: In a message dated 01-09-05 16:14:01 EDT, you write: This is news to me, and certainly no permission has been given to either Compaq nor Covalent to call anything a 'Compaq Apache server.' I am on the ASF board and I can tell you this has not come before us. Actually... it's called the 'Covalent Apache Web Server'. There isn't anything in your board meeting minutes that authorizes that, either. If it says that anywhere on the product, or on Covalent's or Compaq's sites, then the board will ask that it be changed. However, if you are basing this solely on the C!NET article, I do not think that it authoritative enough to warrant any action at all; asking C!NET to clarify would not accomplish much. I do not think that either Covalent or Compaq are using that name, however, and it is a non-issue if they are not. I see Randy has already responded. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
RE: [PATCH] Add mod_gz to httpd-2.0
From: Peter J. Cranstone [mailto:[EMAIL PROTECTED]] Kiss my ass... *delurk* That'll motivate three +1's for mod_gz real quick. :^) (No need for anyone to reply. Just cluttering the list with sophomoric humor.) -Charels
Re: [PATCH] Add mod_gz to httpd-2.0
[EMAIL PROTECTED] wrote: Do you moonlight as a preacher or something? Nope. Do you judge everyone around you like this? Considering that it was an observation rather than a judgement, I suppose I can say that yes, I make observations like that all the time. If you want to 'converse' with Peter then book a flight to Denver. This is EMAIL. No one can ever say all they want to or exepct anyone to ever read it all. It's like 100 different pen-pal sessions going on at the same time. Somehow the rest of us manage to communicate fairly well, though. Of course, sometimes we have to have face-to-face meetings to clear up misunderstandings. :-) And when someone is asked a question, he generally answers, or at least does not take offense when asked repeatedly. I've been reading this forum for 4 years and I certainly don't pretend that anyone here is 'my friend'. Well, I think I am not alone in observing that some of the people here *are* 'my friends.' Why does it work for me (and possibly others) and not you? This is business. Peter made some statements and refused to clarify when asked. Sorry, but if that is business it doesn't sound like *good* business to me. But that is just my opinion, and possibly worthless if it works for RC elsewhere. It may be business to RC, but I think it probably is *not* business for a lot of other people here. Which might be the basis for some of the disconnects. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
In a message dated 01-09-05 17:43:30 EDT, you write: From: Peter J. Cranstone [mailto:[EMAIL PROTECTED]] Kiss my ass... *delurk* That'll motivate three +1's for mod_gz real quick. :^) (No need for anyone to reply. Just cluttering the list with sophomoric humor.) -Charels No problem, Charels... This all just reminds me of some tense board meeting and someone finally cracks a joke and the room breaks out laughing. People are getting some things off their chest here and that's a good thing. It'll be back to business soon enough. Later... Kevin
Re: [PATCH] Add mod_gz to httpd-2.0
Hi Kevin, Guenter Knauf wrote... Hi, I was glad as Ian contributed his mod_gz; I tested it on Linux and Win32 and it works for me. What did you test? that it compiles, loads into server and compresses. How 'heavily loaded' was the Server? you're right, I did only a quick test with some huge text pages; and I didnt compare against your mod_gzip; but real comparing isnt possible yet because then I have to compare also Apache 1.3 with 2.0: I dont have your 2.0 gzip module. Did you just ask for 1 thing, see if it came back compressed, and you are calling that 'success'? see above: I cannot compare against what I dont have. There's a LOT more to it than that. maybe; and after I've read your long letter I see some things clearer... And even if a module compiles without changes and no porting is needed it's not guaranteed to run. The best sample is mod_gzip: I use it on Linux and Win32, but on NetWare the module compiles fine but doesnt work! first of all you see I use your module and I know of the benefits of saving bandwidth or else I woudnt try to get it on all platforms. This was/is an Apache 1.3.x issue only and this issue was resolved on the mod_gzip forum. mod_gzip forum users have been VERY good at helping each other out. mod_gzip for Apache 1.3.x doesn't work 'out of the box' for IBM's rewrite of Apache, either, and in both cases it's because those vendors are re-writing Apache headers and making changes that are not in the standard Apache distributions ( or even available anywhere online ). That's not true! I have downloaded your complete 12MB archive and searched for 'netware': not one thread dealing with NetWare, so please direct me to the message where the issue is solved!! I found 'netware' a couple of times and it was always a #ifdef line from a patch for getting POST to work. I found nothing related to the general failure of mod_gzip on NetWare! Also you can see in your archive what happens to other platforms which are not delivered with a complete C/C++ development as Unix/Linux: they try to compile with Borland and many other things... That's my mainly reason why I want to see a gzip module in the Apache sources: then it will be build for all platforms and distributed with the binaries. With all non *nix platforms you had to buy very expensive compilers; only since a short time we're now able to compile with gcc for Win32 (CygWin) and NetWare (gcc/nlmconv)... That being said... if I recall a number of the Netware problem reports were simply from people that didn't realize you CAN use I wonder who should this be? I know only one other who compiles for NetWare self... and again please show me this reports, in the 12 MB mail archive is nothing! mod_gzip to compress your SSL output but it takes a special configuration. People were reporting output lengths of ZERO in the compression statistics in ACCESS_LOG and didn't realize that what happens is that SSL 'steals away' the connection handles under Apache 1.3.x and delivers the responses outside of the normal Apache delivery process. The pages were being delivered fine but without the special configuration for mod_gzip they were simply not being compressed. Well Kevin, if you believe I'm too stupid to check if I have loaded SSL, TLS or something like that, then we stop discussion here. I told you more than one time that I DONT USE SSL nor TLS nor ANY OTHER MODULE AS THE STANDARD COMPILED IN ONES!!! Also I dont know why you discontinued in helping me find the bug (whereever it sits). I was glad that you immediatly replied a few times and it seemed to me that you were interested in supporting a new platform. Last thing was that I sent you a debug file created from mod_gzip, and I hoped that you could point me to something ot give some hints because you know exactly what your code should do, but then nothing came back... Again: I'm interested in getting mod_gzip working on NetWare with Apache 1.3, I'm able to compile your module as well as the whole server, I have a testmachine and when you give me patches, hints, tips or whatever you have I will test it and let you know the results. There are 'patches' available for mod_gzip that solve the Netware and IBM HTTPD issues. I believe Bill Stoddard himself is currently please point me to this patch or send it to me and I will immediatly check it... I don't personally have/use Netware ( or IBM's HTTPD ) but other users on the mod_gzip forum worked this out for themselves, as any good forum group will do. again: please point me to this patch or send it to me and I will immediatly check it... please notice that I like your module and still interested in getting it working on NetWare... Thanks, Guenter.
Re: [PATCH] Add mod_gz to httpd-2.0
In a message dated 01-09-04 09:35:50 EDT, Jim wrote...
That's right and one of them is...
Will Apache accept ZLIB into the Apache source tree in either
source or binary library format for all platforms.
Check one box only...
[__] Yes
[__] No
Actually, it's not a binary answer... Since Yes implies that the
ASF would accept binary library, which ain't the case, and No implies
that we wouldn't accept source, which may not be
Yea... I guess the minute I hit send I realized that 'if' statement
was missing some 'else'. ROFL
How about this...
Will the Apache group accept the ZLIB source code
into the distribution tree at this time?...
[__] Yes
[__] No
if ( Yes )
{
1. Where will it be? /srclib/zlib?
2. Who is going to add it and when?
}
else
{
Will Apache accept pre-compiled ZLIB libraries into the
source tree ( for any/all platforms )?
[__] Yes
[__] No
if ( Yes )
{
1. Where will the ZLIB libraries be? /srclib/? /support/zlib?
2. Who is going to add them and when?
}
else
{
1. How can anyone vote on adding Ian's mod_gz to the source tree
when the public domain libraries it needs can't be in the source
tree?
2. How is anything in Apache that ever needs ZLIB supposed to
compile? Users must always 'go and get' the libs themselves?
}
}/* End 'else' */
zlib is a very large chunk of code,
Not really... but I guess some might think so.
ASIDE: You really only need the 'compression' part of it. You
are a Server, not a client.
and we resist requiring external
code unless:
1. It's small
2. It's very stable (ie: don't have to keep updating it all the
time, nor worry about passing patches back).
3. It's used by a large chunk of the Apache code (eg: regex).
Does zlib fit the bill?? Well, not for #1 and not really for #3...
Numbers 1 and 2 already sound like the compressor that's
in mod_gzip and is NOT ZLIB ( minus all the debug code, of course ).
It's VERY stable and VERY small ( 20k or so ).
As for number 3... I am still of the opinion that your perspective
is wrong... you are playing 'chicken or egg'. I am of the opinion
that if ZLIB WAS there then in very short order there WOULD
be a 'large chunk of Apache code' that uses it. This is ( and I guess
always has been ) my point.
'Build it and they will come...'
'Include the libs and they will be used ( a lot )...'
Something like that
How in the heck tod the REGEX stuff ever make it in?
Was that some huge 'catch 22' or 'chicken and egg' scenario
as well when it was being proposed?
What was the final straw that broke the stalemate over the
'regexec' library inclusion(s)?
Does that mean we'd never consider it... I'm not willing to say so.
Then it's happening all over again.
Everyone has an opinion but no one will VOTE one
way or the other.
What's it going to take to find out once and for all if
ZLIB can be included in the Apache source tree?
I don't know anymore. I've tried to explain why I think
it would be a great benefit to Apache to have it there
( numerous times going back over a year or more )
and I have tried to supply as much information as I
have about the licensing issues ( IANAL ) and I
have asked for 'real' votes about it... nothing happens...
just more talk.
Somebody else needs to take this into the end-zone.
I don't even know where the football is on this one
anymore.
Yours...
Kevin Kiley
Re: [PATCH] Add mod_gz to httpd-2.0
In a message dated 01-09-04 12:39:44 EDT, Guenter writes... Guenter Knauf wrote... Hi, I was glad as Ian contributed his mod_gz; I tested it on Linux and Win32 and it works for me. What did you test? that it compiles, loads into server and compresses. How 'heavily loaded' was the Server? you're right, I did only a quick test with some huge text pages; and I didnt compare against your mod_gzip; but real comparing isnt possible yet because then I have to compare also Apache 1.3 with 2.0: I dont have your 2.0 gzip module. I wasn't asking if you had tested mod_gzip... You said you had tested 'mod_gz' and that 'it worked' and I was just curious what you were calling 'success'. You don't even say what MIME type you tested. text/plain or text/html? Did you try anything else and did you try it under real circumstances like a fully loaded Server? [rest of message snipped] Guenter... the rest of the message really should have been sent to the mod_gzip forum. Check the title of this message thread... it really concerns someone suggesting that a filtering demo called 'mod_gz' be added to the Apache base tarball. This is not really 'about' mod_gzip at all. I WILL address every point you raised and I will check my notes... I am SURE someone else found the answer as to why Novell's version of Apache is not a standard 'distribution' of Apache and doesn't 'behave' the way 'normal' Apache does. I will locate the info and send it to you. It may be that you have to get the patch from Novell since it's only their 'altered' version of Apache that isn't playing by the rules ( Actually... IBM's rewrite falls into same category but that's not your concern ). Please direct any further mod_gzip 'support' questions to either the mod_gzip forum or to myself. mod_gzip is not part of Apache and these guys are going to explode if this 'please support my Netware' discussion goes any farther on this forum under this message thread. Yours... Kevin Kiley
Re: [PATCH] Add mod_gz to httpd-2.0
On Tue, 2001-09-04 at 12:29, [EMAIL PROTECTED] wrote: ASIDE: You really only need the 'compression' part of it. You are a Server, not a client. we also can be a client. think mod-proxy ..The Weekend Warrior Yours... Kevin Kiley -- Ian Holsman [EMAIL PROTECTED] Performance Measurement Analysis CNET Networks - (415) 364-8608
Re: [PATCH] Add mod_gz to httpd-2.0
On Mon, Sep 03, 2001 at 05:47:02PM -0700, Ryan Bloom wrote: ... I have a big problem with this. We had a hard enough time contributing patches back to MM. The only reason we keep expat and pcre up to date, is that we NEVER make any changes to them. I would be very much against adding zlib to our tree. Not to mention that I'm also an Expat developer, so I can cross-port changes back and forth between the trees. :-) But yes: the stability of PCRE and Expat are a big help. However, I'd point out that we didn't make a lot of changes to MM either; it was quite stable, too. No idea why the changes didn't go back and forth, tho. In fact, the ASF has been a very good influence on Expat. Our ideas are being used for its config/build setup. A lot of the portability work and research that the ASF is good for, is being reflected into Expat to ensure that it is just as portable. Cheers, -g -- Greg Stein, http://www.lyra.org/
the rollup issue (was: Re: [PATCH] Add mod_gz to httpd-2.0)
On Sat, Sep 01, 2001 at 06:19:32PM -0700, Ryan Bloom wrote: ... 3) I don't believe that we should be adding every possible module to the core distribution. I personally think we should leave the core as minimal as possible, and only add more modules if they implement a part of the HTTP spec. The list has already covered the minimalist thing, but the rollup issue is still outstanding. A suggestion: create httpd-rollup to hold the tools/scripts/web pages and whatnot for creating a combo of httpd releases plus supporting modules. The -rollup project could create rollups of just ASF bits (proxy and ???), but could also be a way to rollup third-party modules (like Ralf's module bundles). I believe we have also discussed how the Apache Toolbox could become an ASF project. I'd suggest that it goes into httpd-rollup as one of its outputs. For example: /home/cvs/httpd-rollup contrib-1.3/Apache 1.3 plus a bunch of contrib modules toolbox/Apache Toolbox asf-2.0/Apache 2.0 plus ASF bits contrib-2.0/Apache 2.0 plus ASF plus contribs ... Under httpd-site, we'd create the /rollup/ subdirectory and tightly incorporate references to it with our distribution pages (to ensure that the blob with proxy in it is just as easy to find/download as the core). Does this seem like a reasonable approach to get out of the rollup logjam? Given this kind of arrangement, would some module contributions or inclusion have a lower bar to become part of ASF-distributed bits? etc. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: [PATCH] Add mod_gz to httpd-2.0
[EMAIL PROTECTED] wrote: In a message dated 01-09-04 19:17:25 EDT, Ian writes... ASIDE: You really only need the 'compression' part of it. You are a Server, not a client. we also can be a client. think mod-proxy What current ( or future ) operation would require mod_proxy to 'decompress' something? I would imagine that if mod_proxy can ever accept Content-Encodings it would do what SQUID does... it just stores the response and pays attention to the 'Vary' headers and such but there's never a need to 'decompress' anything. I was thinking that the proxy could request gzip'd data, and possibly get gzip'd returned. it would then examine the client's request and if it can't handle a gzip reply it would ungzip it. (this is the approach that rsync's rproxy takes.) the proxy also reverse-proxies, and the output of that needs to be plain text so it could be merged (via mod-include) (and then possibly gzip'd again) I'm going to run mod_gz through our benchmark lab tomorrow (8-way machine) to see what happens (CPU Usage mainly,and to see if there are any resource leaks) If I get a copy of mod_gzip for 2.0 I will do the same for it. Maintaining an 'object compression' cache is a bit different from regular caching and has to follow different 'rules'. Even if there is a way to store both a compressed and non-compressed version of the same URL in a cache there still isn't any real need to 'decompress' anything. Transfer-encoding: gzip, chunked or some other 'hop to hop' deal is a different story but there's still no known browser that can handle that ( nor any known Proxy that can, either, AFAIK ). check out the work being down by the rproxy.samba.org on rproxy. if we had rsync compression (and a proxy to un-rysnc it) it would be really cool... (especially if mozilla could talk rproxy) but that is pie in the sky. It was just a thought. If people think that ZLIB is 'too big' you can easily cut it in half by only including what you need. nah... I'd rather just link to the one already living on people's systems. the only advantage is if apache's memory pool handling is much faster than zlibs plain old malloc.. but I'm not sold on that (we could link in hoard) Ian... are you a committer? not on Apache, just APR Proxy What do you say about adding ZLIB to Apache source ASAP. Yea or nay? Yours... Kevin Kiley ..Ian
Re: [PATCH] Add mod_gz to httpd-2.0
On Tuesday 04 September 2001 18:23, Greg Stein wrote: On Mon, Sep 03, 2001 at 05:47:02PM -0700, Ryan Bloom wrote: ... I have a big problem with this. We had a hard enough time contributing patches back to MM. The only reason we keep expat and pcre up to date, is that we NEVER make any changes to them. I would be very much against adding zlib to our tree. Not to mention that I'm also an Expat developer, so I can cross-port changes back and forth between the trees. :-) But yes: the stability of PCRE and Expat are a big help. However, I'd point out that we didn't make a lot of changes to MM either; it was quite stable, too. No idea why the changes didn't go back and forth, tho. We actually made a lot of changes to MM. Which is also why the changes didn't go back and forth. We needed things that Ralf didn't want to put in the MM dist. Once we weren't exactly the same, the patching just fell apart. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] Add mod_gz to httpd-2.0
In a message dated 01-09-03 04:55:08 EDT, Henri Gomez writes... Ryan Bloom [EMAIL PROTECTED] wrote: If you want to use gzip, then zip your data before putting it on-line. That doesn't help generated pages, but perl can already do gzip, as can PHP. Let me expose my mod_gzip user experience. I'm using it for more that 9 months on Apache 1.3 servers and never had any problems with it. It's really a great piece of code and all my end users are more than happy to get their stuff quicker. What about asking Jean-loup Gailly and Mark Adler about the leaks in zlib library, and possible fixes ? In case of severe problem, you could still add a warning to mod_gzip potential users. Hi Henri... This is Kevin Kiley. It isn't necessary to ask Jean or Mark about leaks in ZLIB with regards to mod_gzip or add any 'warnings' because mod_gzip does NOT USE ZLIB. There are no 'leaks' of any kind in mod_gzip and since it uses its own context-based control deck for all compression tasks it is 100% thread-safe. Your suggestion is a good one but it would only apply to things that actually use ZLIB such as Ian's 2.0 filtering demo. And Tomcat 4.x :) Pier Hello, Pier, happy to see your here also. Compression is a time consuming task and I'd rather like to see it handled by native code instead of java code. Of course the same thing is true for Crypto operation, and that's why I was more than happy to see mod_ssl contributed to Apache 2.0 :))) Yours... Kevin Kiley
Re: [PATCH] Add mod_gz to httpd-2.0
Hi Henri... This is Kevin Kiley. It isn't necessary to ask Jean or Mark about leaks in ZLIB with regards to mod_gzip or add any 'warnings' because mod_gzip does NOT USE ZLIB. Hi Kevin, happy to see you there :))) You're right, now the gzip code in included in mod_gzip.c and didn't rely anymore on the zlib external lib. And I didn't even noticed :( Question, when did you included the gzip code in mod_gzip ? I remember I've to add -lz -lm when compiling in early age of mod-gzip There are no 'leaks' of any kind in mod_gzip and since it uses its own context-based control deck for all compression tasks it is 100% thread-safe. true... Your suggestion is a good one but it would only apply to things that actually use ZLIB such as Ian's 2.0 filtering demo. And Tomcat 4.x :) Pier May be APR team could use you code to make it available to others modules or apps :!!! Thanks Kevin, I also updated my mod_gzip RPM :
Re: [PATCH] Add mod_gz to httpd-2.0
On Monday 03 September 2001 03:32, Gomez Henri wrote: You're right, now the gzip code in included in mod_gzip.c and didn't rely anymore on the zlib external lib. And I didn't even noticed :( Question, when did you included the gzip code in mod_gzip ? I remember I've to add -lz -lm when compiling in early age of mod-gzip May be APR team could use you code to make it available to others modules or apps :!!! No. APR-util has already become too much of a kitchen sink. There is no reason to include compression in APR or APR-util. If you want to have a compression library, then create a compression library. Do not try to put it into another library. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
RE: [PATCH] Add mod_gz to httpd-2.0
At 12:42 PM -0600 9/2/01, Peter J. Cranstone wrote: It's an amazing analysis of mod_gzip on HTTP traffic and includes all different browser types. Here is what is amazing, check out the saved column and the average savings for all the different stats... About 51% That's a HUGE benefit to ALL apache users. Why wouldn't you use it? Here are my comments regarding mod_gzip... 1. Yes, it's incredibly useful and a worthwhile module. 2. Re: why wouldn't you use it?? As an end-user (sys-admin) I can't think of any real compelling reasons why not... But I think the question you meant was why wouldn't the ASF 'bundle' it with Apache, and the reasons are: 1. Patent issues: I seem to recall that mod_gzip was somehow patented, and with some words to the effect that if it's included with software, then the software follows suit. Before the ASF can consider the module, we must know *exactly* the patent and licensing aspects of the code. 2. ZLIB issues: Because mod_gzip uses ZLIB, we also need to concern ourselves of the nature (patent, licensing, etc...) of that as well. If you can assure us of no viral aspects of the code (or any required code libraries of mod_gzip), no patent issues of any aspects of the code (or it's supporting libraries) and no other conditions of the code donation, then I see no real blocks to the ASF seriously looking at adding the code. As a side point, we really need to do a better job regarding 3rd party modules... Of course, we can't include every 3rd party module that comes down the path, and hopefully module authors realize that. But we do need to make it easier for people to find them, etc... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither
RE: [PATCH] Add mod_gz to httpd-2.0
Jim, 1. There are no patents on any of the technologies contained within mod_gzip. Neither Remote Communications, HyperSpace Communications or either Kevin and I have any patent coverage in this module. 2. Kevin has already covered the licensing issue in detail. (see previous threads) 3. Mod_gzip was released under the Apache style license and you are free to include it. I see no real blocks to the ASF seriously looking at adding the code. I agree. We we've worked hard to release and support a module which Apache users will find useful. It's coming up a year now and people are still downloading it. If the issue is debug code we can always upload a copy which will be about 90% smaller but tougher to understand for the new user. You could use this with Apache distributions and we could carry the full debug version on our site. Regards Peter -Original Message- From: Jim Jagielski [mailto:[EMAIL PROTECTED]] Sent: Monday, September 03, 2001 9:49 AM To: [EMAIL PROTECTED] Subject: RE: [PATCH] Add mod_gz to httpd-2.0 At 12:42 PM -0600 9/2/01, Peter J. Cranstone wrote: It's an amazing analysis of mod_gzip on HTTP traffic and includes all different browser types. Here is what is amazing, check out the saved column and the average savings for all the different stats... About 51% That's a HUGE benefit to ALL apache users. Why wouldn't you use it? Here are my comments regarding mod_gzip... 1. Yes, it's incredibly useful and a worthwhile module. 2. Re: why wouldn't you use it?? As an end-user (sys-admin) I can't think of any real compelling reasons why not... But I think the question you meant was why wouldn't the ASF 'bundle' it with Apache, and the reasons are: 1. Patent issues: I seem to recall that mod_gzip was somehow patented, and with some words to the effect that if it's included with software, then the software follows suit. Before the ASF can consider the module, we must know *exactly* the patent and licensing aspects of the code. 2. ZLIB issues: Because mod_gzip uses ZLIB, we also need to concern ourselves of the nature (patent, licensing, etc...) of that as well. If you can assure us of no viral aspects of the code (or any required code libraries of mod_gzip), no patent issues of any aspects of the code (or it's supporting libraries) and no other conditions of the code donation, then I see no real blocks to the ASF seriously looking at adding the code. As a side point, we really need to do a better job regarding 3rd party modules... Of course, we can't include every 3rd party module that comes down the path, and hopefully module authors realize that. But we do need to make it easier for people to find them, etc... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither
Re: [PATCH] Add mod_gz to httpd-2.0
On Mon, Sep 03, 2001 at 04:40:15AM -0400, [EMAIL PROTECTED] wrote: I suggest (again) that the entire ZLIB source code package be IMMEDIATELY added to the Apache source code tree. Like... TOMORROW. It seems silly to discuss adding anything like mod_gz ( or our Enhanced ApacheBench or any built-in IETF Content-encoding support ) unless it is first determined if either the GZIP source code (GPL license) or ZLIB ( ZLIB/LIBPNG license) will ever make it into the Apache source tree. Votes, anyone? My interpretation of the ZLIB license at http://www.gzip.org/zlib/zlib_license.html leads me to believe that zlib is compatible with the ASF license. I believe OtherBill has already commented on that fact. I do not think that there are any patent issues on zlib - AFAIK, that was the point of writing zlib in the first place. I also think that we do not need to redistribute zlib in our source tree. I think it is common enough now that most OSes come with it. (I look at how we handle the OpenSSL library and think zlib falls in the same category.) If you are willing to post a version of mod_gzip for httpd-2.0 to this list, I will take the time to review it. However, I think there is an advantage to using zlib in this particular case rather than writing our own compression algorithms. -- justin
Re: [PATCH] Add mod_gz to httpd-2.0
On Mon, 3 Sep 2001, Justin Erenkrantz wrote: On Mon, Sep 03, 2001 at 04:40:15AM -0400, [EMAIL PROTECTED] wrote: I suggest (again) that the entire ZLIB source code package be IMMEDIATELY added to the Apache source code tree. Like... TOMORROW. Like, no. It makes zero sense to rush into doing something just to do something without any clear concept of where it is going or what steps really need to be taken to get there. If you are willing to post a version of mod_gzip for httpd-2.0 to this list, I will take the time to review it. However, I think there is an advantage to using zlib in this particular case rather than writing our own compression algorithms. -- justin Also note that, IMO, we do _NOT_ want a mod_g* in 2.0 that has a lot of ugly support trying to make it function in 1.3. I would also like to see more support for the claims that zlib is this horrible thing that just doesn't work properly in a huge number of ways, as tested by the major internet testing companies (whatever the heck that means). In any case, it makes a whole lot more sense to use a library for supporting gzip than to stick it all as custom code into any place that needs it (eg. ab, mod_g*, etc.), even if zlib isn't the library to use.
Re: [PATCH] Add mod_gz to httpd-2.0
From: Justin Erenkrantz [EMAIL PROTECTED] Sent: Monday, September 03, 2001 12:57 PM I also think that we do not need to redistribute zlib in our source tree. I think it is common enough now that most OSes come with it. (I look at how we handle the OpenSSL library and think zlib falls in the same category.) We don't distribute OpenSSL because it's a huge chunk of code!!! We certainly can't rely on folks having 0.9.6b installed (or even 0.9.6a, the absolute minimum to avoid some pretty significant holes, leaving a problem or to remaining.) But we aren't about to distribute that much code, we have a relationship with the maintainers (one sits on the ASF board), and _new_ crypto development still has hardships within the US. There is nothing new or novel about mod_ssl, which is why we have no problem falling under the crypt export relaxation for 'publicly available open sources'. I have no issue with dropping the current (and httpd-maintained) zlib, returning all patches to the authors. If there are problems with threading support + leaks, we will need to fix them if we will call this 'supported'. Same as we do for pcre and expat, which aren't as firmly established as the ASF or even the OpenSSL organization. It adds some 160kb to the tarball, as distributed at zlib.org. Bill
RE: [PATCH] Add mod_gz to httpd-2.0
On Mon, 3 Sep 2001, Peter J. Cranstone wrote: Marc, It makes zero sense to rush into doing something just to do something without any clear concept of where it is going or what steps really need to be taken to get there. Here's a concept Save bandwidth. Here's another one, it's part of the spec. Finally how about we released it under an ASF license. That is irrelevant. We are talking about the proccess of doing something. Just because something _may_ be desirable does NOT mean the proper way to implement it is to jump into doing something tomorrow! Sheesh. The discussion is about adding support to Apache for sending output using the gzip content encoding. There are various different ways to do this, and there is not yet any clear consensus on what the best way is. There are a number of issues that have been raised that do need to be investigated before such a decision can be made. Think then act, not the other way around. Also note that, IMO, we do _NOT_ want a mod_g* in 2.0 that has a lot of ugly support trying to make it function in 1.3. People around the world have been using mod_gzip on Apache 1.3.x for nearly a year. Kevin has supported the product. It has been stable since March. You've abandoned the 1.3.x people for 2.x which is getting closer to beta. As soon as it is you'll have a copy of mod_gzip for 2.x and we will support it. Sorry, that isn't how it works. When 2.0 goes beta, we want to start to _STOP_ adding features, instead of starting to add even more. We (whenever I speak for we, I mean me + my knowledge acquired over the past x years of how things are done around here) will _NOT_ release a product that is Apache 2.0 + some third party module bundled. The product will be Apache 2.0. Either mod_gzip will be an integrated part of that product in terms of development process, etc. or it won't be there at all. A module is not integrated into Apache by some third party saying ok, we will let you have this code when we think you are ready for it, and then we will support it for you. A module is integrated into Apache by the third party becoming a part of us. I'm not sure you have shown the interest in doing so or the ability to understand how the development process works. That certainly doesn't mean we won't consider your code, if you choose to make it available at a time in the product development cycle where we still want to consider adding such functionality, but it does mean that we would take the _code_, at which point you could either find a way to participate in the ongoing Apache development process, or not. I would also like to see more support for the claims that zlib is this horrible thing that just doesn't work properly in a huge number of ways, as tested by the major internet testing companies (whatever the heck that means). Sometimes I wonder where you've been. Only sometimes? I always wonder where I've been... Mercury Interactive has about 60% of the market when it comes to Internet testing. EVERY and I mean EVERY person who is serious about benchmarking uses their Load Runner Umh... maybe you haven't noticed, but there is more to the Internet than the web. Umh... maybe you haven't noticed, but there is a lot more to benchmarking than what Load Runner can do. So by the major internet testing companies, do you mean Mercury Interactive? companies is plural, so I assume there are others. Is that true? Regardless, vague rumors are of no help. Do you have any exact reference that talks about various issues with zlib on a technical level? product... Which, guess what, has just been overhauled to SUPPORT content encoding GZIP which is being used by M$ in IIS 5.0 Guess why the overhauled it. Because people (large financial institutions) are using mod_gzip and Apache and IIS 5.0 and want to know if there is a difference in performance. As the link to those stats yesterday shows, there is indeed a BIG difference and as the latest NetCraft survey shows, Apache is falling every month while IIS gains. This is not a feature, this is PART OF THE SPEC and should have been included from the get go. blah blah blah. It is a feature, pure and simple. There is NOTHING in the HTTP/1.1 spec that says you must send content gzipped to be unconditionally compliant with the spec. You do not advance your argument with random marketoid babble, and I think we would be much more receptive to what you are trying to say if you kept it to a technical discussion. Apache is failing behind the curve. People want to save bandwidth. I don't really care if you include mod_gzip or not, the train has already left the station on this one. Soon it will be the majority who runs compression not the minority. If you don't believe me... Do a FTP search for sites that carry mod_gzip. You'll be surprised. Some very smart people have figured out that this is here to stay. I'm glad that Apache has proven itself to be
Re: [PATCH] Add mod_gz to httpd-2.0
On Mon, Sep 03, 2001 at 12:22:33PM -0700, Justin Erenkrantz wrote: My point is that almost every OS comes with a copy of zlib now. We can't expect most people to have pcre and expat, but I think we can with zlib though. I'd rather not build zlib if we didn't need to. The exception here is probably Win32 (which is why I think you want the source). -- justin How many people compile Apache on Win32 themselves anyway? It should be enough if the person that creates the Apache Win32 binary has zlib installed right? So it really shouldn't be that big of a problem? Of course the sources could be bundled with a guide on how to install zlib on Win32 if you really wanted it anyway.. -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer
Re: [PATCH] Add mod_gz to httpd-2.0
On Mon, Sep 03, 2001 at 01:37:38PM -0600, Jerry Baker wrote: Of course, if it's made as easy as dropping the zlib dist into /srclib (like OpenSSL), then it doesn't matter to me. Oh, I see Makefile.win now. Yes, the Unix build doesn't do that, but for Win32, I bet this is a reasonable solution. If we need to replace zlib, we just check our zlib into srclib. Works for me. -- justin
RE: [PATCH] Add mod_gz to httpd-2.0
Guys, Whatever you want to do. I don't care. Vote on mod_gz for 2.x and mod_gzip for 1.3.x (we submitted this to the ASF last October 13 2000) It's really that simple, you can debate it for evermore. Kevin and I are focused on mod_gzip 2.x which will be released when 2.x goes solid beta. This is my last 2 cents worth. Time's a wasting. Peter -Original Message- From: Sander Striker [mailto:[EMAIL PROTECTED]] Sent: Monday, September 03, 2001 2:32 PM To: [EMAIL PROTECTED] Subject: RE: [PATCH] Add mod_gz to httpd-2.0 Marc, Rather than continue this thread let's see if we can put this subject into the end zone. Think then act, not the other way around. Then vote on it. Either +1 or -1 on including mod_gzip into the Apache distribution. Simple. It isn't as simple as that. You can't just call out a vote to push this through. Lets let this issue settle down first and focus on 2.0 getting good enough for beta. In the mean time mod_gz and mod_gzip (if code is posted) can be reviewed. If there is a maintainer within the ASF, there can be a vote if needed. Otherwise, we don't need a vote, since if the ASF isn't going to maintain it, it isn't going in *. This is what Marc was trying to say aswell I think. I don't think the majority of the httpd developers are going to +1 putting mod_gzip in. Remember that they are the ones having to maintain it and ensure its quality, not you (unless ofcourse you join the development team). Right now it seems like some people are getting worked up and that is not a good environment to make decisions in. Personally I don't even think it is time for this decision. Sander *) At least that is how I understand it and would find it logical to be. Peter. PS. (If I remember rightly I think you already voted +1 on the license for mod_gzip so this should be an easy decision) Things are getting twisted...
RE: [PATCH] Add mod_gz to httpd-2.0
On Mon, 3 Sep 2001, Peter J. Cranstone wrote: Marc, Rather than continue this thread let's see if we can put this subject into the end zone. There are numerous unresolved issues and unanswered questions that have been brought up. The only way to get anywhere is to change them from unresolved to resolved and unanswered to answered and go from there. Think then act, not the other way around. Then vote on it. Either +1 or -1 on including mod_gzip into the Apache distribution. thinking == discussing the issues and coming to a conclusion acting == voting based on that conclusion and then implementing the results of the vote Note again: think _then_ act. There isn't even any code to vote on. Simple. Ok, so what you are saying by not wanting to continue discussion on the issues raised or to answer the questions presented to you is that you aren't interested in working with us to contribute a 2.0 mod_gzip to Apache. That is, of course, a decision that you are free to make. But make sure you understand that it is _you_ deciding this, not anyone else. Alright then, end of thread.
Re: [PATCH] Add mod_gz to httpd-2.0
Ryan Bloom wrote: You know what's really funny? Every time this has been brought up before, the Apache core has always said, if you want to have gzip'ed data, then gzip it when you create the site. That way, your computer doesn't have to waste cycles while it is trying hard to serve requests. I personally stand by that statement. If you want to use gzip, then zip your data before putting it on-line. That doesn't help generated pages, but perl can already do gzip, as can PHP. Neither mod_perl nor mod_php should have to do gzip, as it's a transfer encoding - it should be done transparently. The job of making mod_gzip efficient (AKA not gzipping every file on every request) is the job of mod_cache with cache_storage.c optimisation. mod_gzip should be applied to all output where possible, not just static files. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... S/MIME Cryptographic Signature
Re: [PATCH] Add mod_gz to httpd-2.0
On Monday 03 September 2001 11:36, William A. Rowe, Jr. wrote: From: Justin Erenkrantz [EMAIL PROTECTED] Sent: Monday, September 03, 2001 12:57 PM I also think that we do not need to redistribute zlib in our source tree. I think it is common enough now that most OSes come with it. (I look at how we handle the OpenSSL library and think zlib falls in the same category.) We don't distribute OpenSSL because it's a huge chunk of code!!! We certainly can't rely on folks having 0.9.6b installed (or even 0.9.6a, the absolute minimum to avoid some pretty significant holes, leaving a problem or to remaining.) But we aren't about to distribute that much code, we have a relationship with the maintainers (one sits on the ASF board), and _new_ crypto development still has hardships within the US. There is nothing new or novel about mod_ssl, which is why we have no problem falling under the crypt export relaxation for 'publicly available open sources'. I have no issue with dropping the current (and httpd-maintained) zlib, returning all patches to the authors. If there are problems with threading support + leaks, we will need to fix them if we will call this 'supported'. Same as we do for pcre and expat, which aren't as firmly established as the ASF or even the OpenSSL organization. It adds some 160kb to the tarball, as distributed at zlib.org. I have a big problem with this. We had a hard enough time contributing patches back to MM. The only reason we keep expat and pcre up to date, is that we NEVER make any changes to them. I would be very much against adding zlib to our tree. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] Add mod_gz to httpd-2.0
On Sat, Sep 01, 2001 at 06:19:32PM -0700, Ryan Bloom wrote: On Saturday 01 September 2001 14:56, Justin Erenkrantz wrote: I have a few problems with this. 1) We have consistantly declined to accept the mod_Gzip from remote communications. mod_gzip implements the gzip algorithm. It also happens to be a 300k source file (~11,000 lines). mod_gz is a 14k file and is 446 lines and relies on zlib. Knowing the people on this list I will bet that the size of the file went a long way for us not accepting Remote Communications's version in the core distribution. My cause for not accepting mod_gzip would be that implementing the gzip algorithm is better left to someone else - like the guy who wrote gzip. I mean no offense to Remote Communications as I'm sure their implementation is sound. I will accept the most concise and correct version - at this time, Ian's version is the only one being offered. (My one complaint about mod_gz is that it needs to be moved out of Eastern Europe.) 2) I keep hearing that zlib has more memory leaks than a sieve. As Cliff has pointed out, if there are memory leaks in zlib, then this will sniff them out. Both Opera and Mozilla rely on zlib for handling their gzip Transfer-Encoding. I am sure that their products would benefit if the Apache Group can fix their memory leaks. There hasn't been a release of zlib since 1998. I'm not concerned about this (because if there were memory leaks, *someone* would have addressed them by now). I'm also not amused by the suggestion that this may be a security hole. This is a read-only operation that we are performing. 3) I don't believe that we should be adding every possible module to the core distribution. I personally think we should leave the core as minimal as possible, and only add more modules if they implement a part of the HTTP spec. I believe that this does implement a core component of the HTTP spec - namely Transfer-Encoding. Most current browsers have gzip support built-in (Netscape, Opera, and Mozilla do - I bet IE does, but I don't use it) - however, we have never supported this. I believe it is time that we do so. Not having implemented this is a major oversight on our part. Putting every module into the core is NOT the answer to this problem. IMNSHO, Apache should be a minamilistic web server. If we don't need it in the core, it shouldn't be there. Personally, I would remove mod_dav from the server too, because it doesn't implement part of RFC2616. I believe that DAV belongs in our standard module set because it is treated as an extension to HTTP. The same goes for our inclusion with SSL. I believe that anything that adds value to the server out-of-the-box belongs in the main repository. Things like mod_pop3 and mod_mbox are special modules that no one really cares much about. We did them as proofs of concepts - if they help, cool, but they aren't part of the officially supported httpd-2.0 code - you don't want to maintain or enhance mod_pop3 and I don't want to maintain or enhance mod_mbox. My +1 for adding this to the core distribution of modules stands. I fully believe that adding this functionality to the server is completely worth it. Can I either receive two more +1s or a straight out veto? (AIUI, a non-veto -1 is treated as a -0. Please correct me if I am wrong.) -- justin
Re: [PATCH] Add mod_gz to httpd-2.0
Justin Erenkrantz wrote: mod_gzip implements the gzip algorithm. It also happens to be a 300k source file (~11,000 lines). mod_gz is a 14k file and is 446 lines and relies on zlib. Knowing the people on this list I will bet that the size of the file went a long way for us not accepting Remote Communications's version in the core distribution. My cause for not accepting mod_gzip would be that implementing the gzip algorithm is better left to someone else - like the guy who wrote gzip. I mean no offense to Remote Communications as I'm sure their implementation is sound. If I recall correctly, this "guy who wrote gzip" (or - to be precise - one of the two guys who wrote it) is working with Remote Communications. If it's true, it means that he feels OK with their implementation (maybe it's similar?). Having one less library to depend on, is an advantage and not a disadvantage, even if it requires mod_gzip to be 300K (I believe that the 2.0 version will be smaller, thanks to the I/O filtering). Maybe we should simply ask him; His name is Mark Adler, more details at: http://www.alumni.caltech.edu/~madler/ Note: I don't know mod_gz but only mod_gzip. -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel
Re: [PATCH] Add mod_gz to httpd-2.0
On Sat, Sep 01, 2001 at 07:50:19PM -0700, Ryan Bloom wrote: On Saturday 01 September 2001 18:53, Cliff Woolley wrote: On Sat, 1 Sep 2001, Ryan Bloom wrote: ... 2) I keep hearing that zlib has more memory leaks than a sieve. Maybe it does, but that can be dealt with. Even so, it shouldn't be a consideration here IMO, at least not yet. If it really is leaky (which it very well might be but we should prove it rather than just going on what we heard), then it's a consideration, but it'd be better for somebody to just *fix* zlib than for us to throw out both mod_gz and mod_gzip because of zlib's deficiencies (assuming we care, which we probably do). I disagree that this shouldn't be a consideration. If we are distributing a module that relies on a library that leaks, then we are suggesting people use a leaking library. I would be fine fixing zlib, but if that can't be done, then a memory leak in zlib would make me a -0.5 very quickly. We ship code that uses it. zlib fixes their code (or somebody else fixes it). Now our module rocks. Chicken and egg... A ton of other projects use zlib. I see no reason for us to avoid it. If it *does* happen to have leaks, then (when somebody finds this to be true) they could fix it. 3) I don't believe that we should be adding every possible module to the core distribution. I personally think we should leave the core as minimal as possible, and only add more modules if they implement a part of the HTTP spec. The gzip content encoding is part of the HTTP spec. My personal opinion is that this one is important enough that it should go in. Most clients support gzip transfer coding, and it's a very real solution to the problem of network bandwidth being the limiting factor on many heavily-loaded web servers and on thin-piped clients (read: modem Agreed! users). mod_gz(ip) could provide a significant throughput improvement in those cases, where the CPU is twiddling its thumbs while the network pipe is saturated. This fills a gap in Apache that could be a very big deal to our users. (It's not like it's a big or obtrusive module either, but size is not the final consideration in what goes in and what doesn't.) You know what's really funny? Every time this has been brought up before, the Apache core has always said, if you want to have gzip'ed data, then gzip it when you create the site. That way, your computer doesn't have to waste cycles while it is trying hard to serve requests. I personally stand by that statement. If you want to use gzip, then zip your data before putting it on-line. That doesn't help generated pages, but perl can already do gzip, as can PHP. But it isn't invisible if you do it with Perl, PHP, Python, or CGI. A person has to explicitly code it. I'm really looking forward to mod_gz(ip) in Apache 2.0 so that Subversion can transfer its content in compressed form. All of that comes out of a database... it can't be precompressed, so that leaves a filter to do the job as it hits the wire. Doing large checkouts are almost *always* network bound rather than server/client bound. Compressing those files is a *huge* win. -1 (vote, not veto), for putting mod_gz in the core. Please use -0.9 or something. It gets really confusing to see -1 and never know what it means. As I've said before: -1 really ought to always mean a veto. But... that's just me :-) Needless to say, I'm +1 on the concept. It's a big win for everybody. I haven't reviewed the code yet, so no commentary there. Cheers, -g -- Greg Stein, http://www.lyra.org/
RE: [PATCH] Add mod_gz to httpd-2.0
Hi, From what I have seen on the list I am on the +1 side of adding mod_gz(ip) to the distribution. Ofcourse, my vote doesn't count since I don't have httpd commit. I find the following arguments convincing (summarized): - The gzip content encoding is part of the HTTP spec. - Most clients support gzip transfer coding. - It is a real solution to the problem of network bandwidth being the limiting factor on many heavily-loaded web servers and on thin-piped clients. - It makes the compression transparent to the admin of the site and allows for dynamically generated content (which can grow quite large) to be compressed aswell. I haven't seen anything that held on the negative side yet. Sander
Re: [PATCH] Add mod_gz to httpd-2.0
On Sat, Sep 01, 2001 at 06:19:32PM -0700, Ryan Bloom wrote: zlib has more memory leaks than a sieve. 3) I don't believe that we should be adding every possible module to the core distribution. I personally think we should leave the core as minimal as possible, and only add more modules if they implement a part of the HTTP spec. though not *required* by the HTTP spec, there is a clear signal from it that compression should be supported by default. If you don't believe me, just ask the spec authors ! Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ [EMAIL PROTECTED] | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
RE: [PATCH] Add mod_gz to httpd-2.0
Hi, I was glad as Ian contributed his mod_gz; I tested it on Linux and Win32 and it works for me. The problem I see with 3rd party modules is not mainly that they are 'invisible', I've found tons of modules and often 3 or more for the same purpose, but many modules were only written for Unix and fail to compile on other platforms because they often heavily use system libs which arent available on the new target; so many modules must be ported to the target os and the concept of the Apache api is gone. And even if a module compiles without changes and no porting is needed it's not guaranteed to run. The best sample is mod_gzip: I use it on Linux and Win32, but on NetWare the module compiles fine but doesnt work! I think this will not happen with Ian's module because it uses only Apache apis, so once the server runs on a platform mod_gz will do too (ok, as far as zlib is ported to that platform, but that's true for nearly every platform). I was also in contact with Kevin, but he couldnt help me with the issue on NetWare... Ian, I'll chat with Kevin on getting you a copy of the code. Although I think he will want to wait until Apache 2.x goes beta. He's the author and it's his decision. please ask Kevin for a copy for me too. Thanks! Guenter. PS: if you take a look at mod_gzip 1.3.xx you will see that more than half of the 300k are only debug messages...
RE: [PATCH] Add mod_gz to httpd-2.0
Hi All, I think Sander sum it up nicely. - It is part of the spec. Apache should implement the spec. - Almost all new browsers support IETF content encoding/transfer encoding. In testing with MSIE 6.x and Netscape 6.1 compression works fine. - The biggest users of mod_gzip are outside the USA. Why? Because they pay for bandwidth. - There are some large institutions (financial markets) that use mod_gzip to reduce HTML/JavaScript etc. - It supports dynamic and static content. - You can compress SSL (with some hacks) A couple of other issues. - Netware. With a little help this can be fixed. However the majority of the net runs either Apache, IIS, iPlanet or Zeus. - Apache 2.x is not yet stable for all platforms. - Debug code and size of mod_gzip... We can remove the debug code. It's stable enough now after 9 months of solid testing to pull it. In closing... Here is the biggest reason to include mod_gzip -- compression (transfer encoding/content encoding) part of the HTTP spec! -- for those who hate long emails you can stop reading here soap box Apache's market share dropped last month. Micro$oft IIS 5.0 is making headway and IT INCLUDES AN ISAPI GZ FILTER. It happens to be a pig and it does not support compressed POST transactions (mod_gzip does) and it has issues compressing Javascript. But bottom line, Microsoft is supporting the standard and even though the first pass is rough it will get better. Which means that if people figure out what European users have been saying for nearly a year that compressing HTML etc really makes a difference then Apache needs to embrace the light. Mod_gzip was released with an Apache style license with this thought in mind. The writing is on the wall, if Micro$oft sees a benefit to adding compression then it's only a matter of time before everyone is demanding it be there. My thought is that it would be better for Apache to be first rather than playing catch up. On a personal note. Kevin and I have been on this forum long enough to know what the rules are. We released mod_gzip under an Apache style license for one reason. So Apache would benefit. Sure Kevin is the author and has continued to do an incredible job supporting the code, but now others have joined the mod_gzip forum and have taken up the challenge. On October 13th 2001 it will have been a year since the code came out. It has not undergone any changes since March 2001 and is now considered stable for Apache 1.3.x users. The 2.x version is only waiting for one thing which is *beta*. What the server is stable enough to run for months and users are upgrading to the new version we will release mod_gzip for 2.x under exactly the same license as 1.x version. end Regards Peter -Original Message- From: Sander Striker [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 02, 2001 6:12 AM To: [EMAIL PROTECTED] Subject: RE: [PATCH] Add mod_gz to httpd-2.0 Hi, From what I have seen on the list I am on the +1 side of adding mod_gz(ip) to the distribution. Ofcourse, my vote doesn't count since I don't have httpd commit. I find the following arguments convincing (summarized): - The gzip content encoding is part of the HTTP spec. - Most clients support gzip transfer coding. - It is a real solution to the problem of network bandwidth being the limiting factor on many heavily-loaded web servers and on thin-piped clients. - It makes the compression transparent to the admin of the site and allows for dynamically generated content (which can grow quite large) to be compressed aswell. I haven't seen anything that held on the negative side yet. Sander
RE: [PATCH] Add mod_gz to httpd-2.0
Hi, A couple of other issues. - Netware. With a little help this can be fixed. However the I will provide any help I can give; I'm able to compile and run the module, I've compiled the debug version and have already sent an output to Kevin; the issue is that the work files are always empty...(he assumed that I use SSL but I didnt load any other modules except status and info). majority of the net runs either Apache, IIS, iPlanet or Zeus. yes, I run Apache on NetWare. - Debug code and size of mod_gzip... We can remove the debug code. It's stable enough now after 9 months of solidtesting to pull it. I didnt mention it as negative but only to explain why the code is 300kb; and it's very useful when the module doesnt run as on NetWare... If you want to help me a bit in finding out why it doesnt work with NetWare feel free to contact me directly... Thanks, Guenter. PS: I have also another issue with mod_gzip together with a counter module: when mod_gzip is loaded the counter increments 2 times every access (true on all platforms, but maybe the counter isnt clean).
Re: [PATCH] Add mod_gz to httpd-2.0
From: Jerry Baker [EMAIL PROTECTED] Sent: Saturday, September 01, 2001 10:32 PM Ryan Bloom wrote: You know what's really funny? Every time this has been brought up before, the Apache core has always said, if you want to have gzip'ed data, then gzip it when you create the site. That way, your computer doesn't have to waste cycles while it is trying hard to serve requests. I personally stand by that statement. If you want to use gzip, then zip your data before putting it on-line. That doesn't help generated pages, but perl can already do gzip, as can PHP. Gzip'ing html into files is a hopeless waste of disk space and clutter. That means for every file you have to have a gzipped and non-gzipped version for browsers that cannot handle it. Then you have to configure Apache to check for and serve the proper file to the proper browser. It makes Web page maintenance a severe PITA as you have to re-gzip a doc everytime it is modified and upload both files. Interesting point for gzip authors in general ... if it won't save a second network packet - it is _not_ worth it (think favicon.ico, icon.gif (or any self-compressed format), or littleframeset.html). Probably always need to set some 'threshhold' of 8kb (minimally) that the webserver absolutely ignores, and some include or exclude list by mime type to describe the value of further compression. Even if the file is requested to be gzip'ped, and it's targetted for the cache, set a flag at the end that says hey, I saved -2% on this file, don't let us do _that_ again! File foo shouldn't be cached, and then internally add foo to the excludes list for any gzip filter. Bill
Re: [PATCH] Add mod_gz to httpd-2.0
Ryan Bloom wrote: I believe that putting a module into the core says that we are willing to support it, and that we believe the quality of the module is as high as the rest of the core. With that I can certainly agree. I would like to make that statement as few times as possible. See, *that* I would like to say as *many* times as possible, with equal confidence in all cases. The more we say it, the more likely we are to be wrong once. That sounds like letting 'we should' wait upon 'we dare not.' :-) I do not know about anyone else, but I personally think the effort has historically been directed toward making Apache as featureful and *good* as possible, not making it perfect and keeping it so small that we limit functionality in order to keep out the possibility of bugs. Warts go along with this stuff. One of the strong facets has been letting people work on whatever they want to work on, as long as they were willing to support it, and nearby eyeballs would help watch for bugs. Saying you can do that only within a limited set of rules is, IMHO, contrary to the spirit of the project. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
Ryan Bloom wrote: If we don't need it in the core, it shouldn't be there. Since there is no reason to drive 100+ MPH, auto manufacturers should not make vehicles capable of going that fast. 'Needed in the core' -- what of the current modules are 'needed by the core?' Nothing in the core needs mod_speling, or mod_rewrite, or... I think this is a cockeyed metric to use. Un- or insufficiently- tested modules, maybe, but shutting things out because of 'core need'? I do not think that is valid. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
From: Ryan Bloom [EMAIL PROTECTED] Sent: Saturday, September 01, 2001 10:50 PM On Saturday 01 September 2001 20:10, Cliff Woolley wrote: Perhaps modules distributed through official httpd subprojects are more visible/more trusted, but we don't really know one way or the other on that front yet. I can agree with this, but this is something we need to fix. There are many ways to fix it. Fixing modules.apache.org would be a very good first step. ++1, we want to _highlight_ our extra projects at http://httpd.apache.org/more/! And perhaps provide some links from pages like manual/mod/index.html with a Not here? Try the third-party modules, (registered by their authors) at http://modules.apache.org/; for completeness. Putting every module into the core is NOT the answer to this problem. IMNSHO, Apache should be a minamilistic web server. If we don't need it in the core, it shouldn't be there. Personally, I would remove mod_dav from the server too, because it doesn't implement part of RFC2616. I was thinking about this. We are discussing if /modules/proxy/ should be readded to the core tree over at [EMAIL PROTECTED] My observation there is that the RFC for mod_proxy may be expanded outside of the http schema in the future. We already have adjunt Connection-Upgrade/tls over http extensions to that RFC. This argument will give us headaches until we decide some simple rules to add a module as a core or sub project. WebDAV isn't a 'done' protocol, and really started out as the WebDA protocol (versioning deferred until we figure out how it should be described.) I'm sure it will grow. mod_ssl isn't 'done' either, until we implement the Connection-Upgrade schema. Not only are some folks in the world bound _never_ to download it (as it is in conflict with their own laws) but some folks in the world are prohibited by the US from downloading it (the T5). And it too is supplimented by the TLS RFCs. One thorn in everyone's side was that mod_proxy implemented a HTTP/1.0 superset, although the rest of the server was essentially HTTP/1.1. IMHO, if a modules is on a different standards track (or likely to be extended on one) it should probably live in it's own subproject. Who on the proxy team wants to wait for the core to bump a version just because proxy wants us to. The proxy team finishes implementation of another extension, they want to get an alpha/beta/release out the door! If they implement another proxy-protocol, they want to get that out the door (sftp anyone?) How about one last example ;-? Lets say SQL support is deemed 'important'. An httpd-sql subproject might implement several aaa modules, with some additional support/ apps, to allow SQL stuff. Then they get the hairbrained idea to .htaccess as a SQL table (for performance.) This project could grow (with a charter of 'extending httpd core file-based mechanisms through a generic SQL layer') as far as they wanted to take it. In a perfect world, apache-2.0.26-gold-core.tar.gz contains just the core. Then give the world apache-2.0.26-gold-all-gold-20010915.tar.gz with all _released_ subprojects effective 2001.09.15 rolled in! The adventurous could try the apache-2.0.26-gold-all-beta-20010915.tar.gz. Finally, the looney (most folks that follow this list) can grab apache-2.0.26-gold-all-alpha-20010915.tar.gz for alpha releases of every module (probably a longer list, since some subprojects at a given time likely haven't gone gold just yet.) Subprojects would probably have an easier time with a user of the gold apache core release, since the bugs are more likely to be _in_ their module, not somewhere else. Now we stand a (small) chance of keeping up. Add some decent user support outside of the (sometime now hard-to-reach) nttp support in comp.infosystems.www.servers. and these could be really useful. With a [EMAIL PROTECTED], [EMAIL PROTECTED], proxy-users... and actually make that a really strong system, by using mod_mbox on http://httpd.apache.org/ to allow folks to browse those threads. We must be one of the last strong projects with _no_ user's list (what's up with that ;-?) Subprojects shouldn't be our orphans. The give small author groups well deserved recognition. They need to become our crowning jewels. Bill
Re: [PATCH] Add mod_gz to httpd-2.0
On Sun, Sep 02, 2001 at 12:43:09PM -0500, William A. Rowe, Jr. wrote: The gzip content encoding is part of the HTTP spec. By implementation, or reference? Sure Content-encoding is part of the spec, and it's defined to allow authors to extend their support to any number of encodings, and forces the server to use only what the client claims as supported encodings. gzip is mentioned explicitly in RFC 2616 as a supported content-encoding (one registered with IANA). +1 with caviat to follow. Cool. BTW, do these +1 (concept) votes count towards mod_gz's inclusion? I now count three binding +1 (concepts) for this (Cliff, Greg, and OtherBill). Or, do I need to wait until I receive two +1s for mod_gz explicitly? So we need any gzip filter to drop out quick if 1. it knows this mime type should not be encoded; 2. it sees the content-encoding is already gz; 3. it sees the uri/filename whatever in a list of exclusions (that could be automagically grown when it hits files that _just_don't_compress_well_. I would think that this is a httpd.conf configuration issue. Remember, we add mod_gz via: AddOutputFilter GZ html Ian's version did make sure that the content-type was text/html before encoding. But, I don't think that is necessary. If the admin sets mod_gz via the OutputFilter semantics, that's their wish (remember, you must *ask* for mod_gz). I'd rather not see these types of assumptions in any gzip module we implement. (I need to double check that mod_gz and mod_include don't interfere with each other...mod_gz should run *after* mod_include has processed the data...) If we like, the entire zlib (168kb tar/gz'ed) could be distributed through /srclib/ instead of by reference. It really isn't that large, and matches what we do today with pcre and expat. If we like, drop it into apr-util/encoding/unix/lib/zlib and only expose it through thunks (allowing someone to come up with more robust or faster apr-util thunks to source that we can _not_ redestribute.) The more I contemplate, the stronger my +1 for apr-util remapping, where appropriate on some platforms. Almost every platform I am aware of includes zlib by default now. Solaris, AIX, Linux, FreeBSD. Ian has all of the MSVC files (I didn't post them as I want to place it in modules/filters which is different than where Ian originally had it) - so I know he has something working on Win32. So, I don't think that we need to distribute zlib. Nor do we need to perform thunking. It's just so common now. AIUI, zlibc is completely transparent to any application. -- justin
Re: [PATCH] Add mod_gz to httpd-2.0
Hello all... Kevin Kiley here... Here is a mixture of comment/response regarding mod_gzip and the ongoing conversation(s)... There is a (short) SUMMARY at the bottom. Justin ErenKrantz's original post... Ian has posted his mod_gz filter before, now I'd like to give it a +1. I told him I'd look at it a while ago, but never got a chance to do so. So, I spent this morning cleaning up the configuration and a bit of the code to fit our style (nothing major). I'd like to add this to the modules/filters directory (which seems like the most appropriate place). Justin Ryan Bloom responded... I have a few problems with this. 1) We have consistantly declined to accept the mod_Gzip from remote communications. Correct... and for a while the reason was because everyone thought the module was using ZLIB and there has been a long standing aversion to including ANY version of GNU ZLIB ( or any other GNU stuff ) into the Apache tree. We have personal emails from your board members stating that to be the case. If that aversion has evaporated then there is a TON of GNU based stuff that is now 'eligible' for inclusion in the core distribution, right? GNU issues aside... we have consistently been told that the other reason mod_gzip would not be included is because of the 'support' issue. Apache has a standing rule that no module goes into the distribution unless you are absolutely SURE that it will be adequately supported. Makes sense. We have been consistently supporting this technology for years now. Ian himself said he 'Just got bored and decided not to do any real work one weekend' and cranked out a filter demo that happened to include ZLIB. He has not demonstrated any intention of actually 'supporting' it other than making a few modifications to the 'demo' ( and even those have yet to appear ). If that doesn't raise the issue of 'will it be supported' I don't know what would. mod_gzip has NEVER used 'ZLIB' for a number of reasons... the primary one being that ZLIB is inadequate for the purpose. ZLIB is a non-multithread-safe file based compression library. The secondary reason is actually so that you folks wouldn't have to worry about the 'GNU' issues you have if/when you wanted to use the code. Read the comments at the top of mod_gzip.c right underneath the Apache license section which has always been at the top of mod_gzip and the syntax of which was personally approved by at least 3 of your top level board members via personal email(s). 2) I keep hearing that zlib has more memory leaks than a sieve. It does. Any non-multithread-safe file oriented library does if you just slap it into a multithread environment and start using it without putting critsecs around the calls to serialize it. 3) I don't believe that we should be adding every possible module to the core distribution. That's always been the rule. It is still a mystery when/how something 'rises' to the level of importance to be included in the Apache distribution ( E.g. WebDav, etc ). That being said... see next comment. I personally think we should leave the core as minimal as possible, and only add more modules if they implement a part of the HTTP spec. mod_gzip does that. It makes Apache able to perform the IETF Content-Encoding specification that has ALWAYS been a part of HTTP 1.1. Before this goes into the main tree, I think we need to seriously think about those topics. Think HTTP 1.1 compliance. I would be MUCH happier if this was a sub-project, or just a module that Ian distributed on his own. Ryan Cliff Wooley wrote... Ryan Bloom wrote... I have a few problems with this. 1) We have consistantly declined to accept the mod_Gzip from remote communications. That's true, though that was for 1.3. Just now with Peter's message is the first time I've heard that mod_gzip for 2.0 was even nearing release. I'm not prejudiced... whichever one is better wins. :) We have said any number of times that even the ORIGINAL version of mod_gzip was coded/tested against the ORIGINAL (alpha) release of Apache 2.0. It was only when we realized how long Apache 2.0 was away from either a beta or a GA that we ported it BACKWARDS to Apache 1.3.x so people could start using it right away... and they have ( thousands of folks ). As recently as a few weeks ago we said again that a 2.0 version of mod_gzip was 'ready to go' but we just wanted to make sure the filtering API's were going to stop changing ( which they still were at the time ). Now our only concern is that the filtering I/O is actually WORKING the way it is supposed to from top to bottom. Even recent messages regarding Content-length support and such indicate there is still some work to be done. We just want the existing Apache 2.0 I/O scheme to be CERTIFIED by the people that wrote it ( E.g. BETA at least ) before we CERTIFY our own product(s) against that same Server product. If you were conviced that mod_gzip was only for Apache 1.3.x then
Re: [PATCH] Add mod_gz to httpd-2.0
In contrast, with an 11,000-line implementation like mod_gzip, it's much less likely that other developers will be able to troubleshoot the code quickly if it breaks while the original authors are on vacation. A quick perusal of thesource for the 1.3 version of mod_gzip (which I've been happily using for 3 weeks now), leads me to believe that 90% of the 11,000 lines are debug code #ifdef'd out.
Re: [PATCH] Add mod_gz to httpd-2.0
Ryan Bloom [EMAIL PROTECTED] wrote: If you want to use gzip, then zip your data before putting it on-line. That doesn't help generated pages, but perl can already do gzip, as can PHP. And Tomcat 4.x :) Pier
Re: [PATCH] Add mod_gz to httpd-2.0
On Saturday 01 September 2001 14:56, Justin Erenkrantz wrote: I have a few problems with this. 1) We have consistantly declined to accept the mod_Gzip from remote communications. 2) I keep hearing that zlib has more memory leaks than a sieve. 3) I don't believe that we should be adding every possible module to the core distribution. I personally think we should leave the core as minimal as possible, and only add more modules if they implement a part of the HTTP spec. Before this goes into the main tree, I think we need to seriously think about those topics. I would be MUCH happier if this was a sub-project, or just a module that Ian distributed on his own. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] Add mod_gz to httpd-2.0
On Sat, 1 Sep 2001, Ryan Bloom wrote: On Saturday 01 September 2001 14:56, Justin Erenkrantz wrote: I have a few problems with this. 1) We have consistantly declined to accept the mod_Gzip from remote communications. That's true, though that was for 1.3. Just now with Peter's message is the first time I've heard that mod_gzip for 2.0 was even nearing release. I'm not prejudiced... whichever one is better wins. :) I don't suppose the guys at Remote Communications would be willing to share the code for mod_gzip for 2.0 with some of us developers privately so that we can get a feel for it before it's released publicly, would they? 2) I keep hearing that zlib has more memory leaks than a sieve. Maybe it does, but that can be dealt with. Even so, it shouldn't be a consideration here IMO, at least not yet. If it really is leaky (which it very well might be but we should prove it rather than just going on what we heard), then it's a consideration, but it'd be better for somebody to just *fix* zlib than for us to throw out both mod_gz and mod_gzip because of zlib's deficiencies (assuming we care, which we probably do). 3) I don't believe that we should be adding every possible module to the core distribution. I personally think we should leave the core as minimal as possible, and only add more modules if they implement a part of the HTTP spec. My personal opinion is that this one is important enough that it should go in. Most clients support gzip transfer coding, and it's a very real solution to the problem of network bandwidth being the limiting factor on many heavily-loaded web servers and on thin-piped clients (read: modem users). mod_gz(ip) could provide a significant throughput improvement in those cases, where the CPU is twiddling its thumbs while the network pipe is saturated. This fills a gap in Apache that could be a very big deal to our users. (It's not like it's a big or obtrusive module either, but size is not the final consideration in what goes in and what doesn't.) --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: [PATCH] Add mod_gz to httpd-2.0
From: Pier Fumagalli [EMAIL PROTECTED] Sent: Saturday, September 01, 2001 8:57 PM Ryan Bloom [EMAIL PROTECTED] wrote: 3) I don't believe that we should be adding every possible module to the core distribution. I personally think we should leave the core as minimal as possible, and only add more modules if they implement a part of the HTTP spec. I can't say much, as I'm not a developer of HTTPD, but I tend to share the feeling with Ryan on this. In the light of the latest security warnings on Tomcat, adding a single feature (CGI execution), compromised our entire core... And as Chuck forwarded to the members, it might be worth reading this http://www.zdnet.com/zdnn/stories/news/0,4586,2792860,00.html. Adding features to the core, unless they're absolutely 100% safe and 100% needed is, IMVVVHO, not a very good idea... I concur. I'd also point out that the more thoroughly we can document the new hooks architechture, and expose the apr/apr-util/libhttpd api to the third party developers, the more secure their modules stand to be. By instituting additional internal interlocks (e.g. the request must have the dir_walk/file_walk success tag before the core handler will work) and a very predictable schema, that is successfully optimized, module authors won't spend as much time hacking 'around' the core, and we will all enjoy significantly fewer new holes in 2.0. Let's make 2.0 the most _predictable_ release ever, and everyone benefits :-) Bill
Re: [PATCH] Add mod_gz to httpd-2.0
On Saturday 01 September 2001 18:53, Cliff Woolley wrote: On Sat, 1 Sep 2001, Ryan Bloom wrote: On Saturday 01 September 2001 14:56, Justin Erenkrantz wrote: I have a few problems with this. 1) We have consistantly declined to accept the mod_Gzip from remote communications. That's true, though that was for 1.3. Just now with Peter's message is the first time I've heard that mod_gzip for 2.0 was even nearing release. I'm not prejudiced... whichever one is better wins. :) Remote Communications has been very vocal about having ported to 2.0 for a very long time. I don't suppose the guys at Remote Communications would be willing to share the code for mod_gzip for 2.0 with some of us developers privately so that we can get a feel for it before it's released publicly, would they? Their code has always been open source. Their 1.3 code is basically based on code from Krow at /. 2) I keep hearing that zlib has more memory leaks than a sieve. Maybe it does, but that can be dealt with. Even so, it shouldn't be a consideration here IMO, at least not yet. If it really is leaky (which it very well might be but we should prove it rather than just going on what we heard), then it's a consideration, but it'd be better for somebody to just *fix* zlib than for us to throw out both mod_gz and mod_gzip because of zlib's deficiencies (assuming we care, which we probably do). I disagree that this shouldn't be a consideration. If we are distributing a module that relies on a library that leaks, then we are suggesting people use a leaking library. I would be fine fixing zlib, but if that can't be done, then a memory leak in zlib would make me a -0.5 very quickly. 3) I don't believe that we should be adding every possible module to the core distribution. I personally think we should leave the core as minimal as possible, and only add more modules if they implement a part of the HTTP spec. My personal opinion is that this one is important enough that it should go in. Most clients support gzip transfer coding, and it's a very real solution to the problem of network bandwidth being the limiting factor on many heavily-loaded web servers and on thin-piped clients (read: modem users). mod_gz(ip) could provide a significant throughput improvement in those cases, where the CPU is twiddling its thumbs while the network pipe is saturated. This fills a gap in Apache that could be a very big deal to our users. (It's not like it's a big or obtrusive module either, but size is not the final consideration in what goes in and what doesn't.) You know what's really funny? Every time this has been brought up before, the Apache core has always said, if you want to have gzip'ed data, then gzip it when you create the site. That way, your computer doesn't have to waste cycles while it is trying hard to serve requests. I personally stand by that statement. If you want to use gzip, then zip your data before putting it on-line. That doesn't help generated pages, but perl can already do gzip, as can PHP. -1 (vote, not veto), for putting mod_gz in the core. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] Add mod_gz to httpd-2.0
On Sat, 1 Sep 2001, Ryan Bloom wrote: Their code has always been open source. Their 1.3 code is basically based on code from Krow at /. I know that. But the 2.0 version is supposed to be vastly different (less complex) than the 1.3 version, from what I remember. I'd just like to see it. shrug --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: [PATCH] Add mod_gz to httpd-2.0
Taking a step back from gz for a moment, and speaking in general: On Sat, 1 Sep 2001, Ian Holsman wrote: 3rd party modules are invisible to most people, I'll agree with that statement... we can tell ourselves that it's okay to push off modules onto third-party distribution, but the fact is that if it doesn't come as a standard module, people are much less likely to go get it unless they have absolutely no other choice because they either are too lazy, don't know it exists, or fear its stability/security because it's third-party. Perhaps modules distributed through official httpd subprojects are more visible/more trusted, but we don't really know one way or the other on that front yet. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: [PATCH] Add mod_gz to httpd-2.0
Ryan Bloom wrote: You know what's really funny? Every time this has been brought up before, the Apache core has always said, if you want to have gzip'ed data, then gzip it when you create the site. That way, your computer doesn't have to waste cycles while it is trying hard to serve requests. I personally stand by that statement. If you want to use gzip, then zip your data before putting it on-line. That doesn't help generated pages, but perl can already do gzip, as can PHP. Gzip'ing html into files is a hopeless waste of disk space and clutter. That means for every file you have to have a gzipped and non-gzipped version for browsers that cannot handle it. Then you have to configure Apache to check for and serve the proper file to the proper browser. It makes Web page maintenance a severe PITA as you have to re-gzip a doc everytime it is modified and upload both files. -- Jerry Baker PGP Key: http://www.jerrybaker.org/pgp.html LAME MP3 Encoder Binaries: http://www.jerrybaker.org/lame/ Apache 2.0 Web server Installer: http://www.jerrybaker.org/apache/
RE: [PATCH] Add mod_gz to httpd-2.0
You know what's really funny? Every time this has been brought up before, the Apache core has always said, if you want to have gzip'ed data, then gzip it when you create the site. That way, your computer doesn't have to waste cycles while it is trying hard to serve requests. I personally stand by that statement. If you want to use gzip, then zip your data before putting it on-line. That doesn't help generated pages, but perl can already do gzip, as can PHP. A couple of points here - a lot of authors can't easily zip content before putting it on-line. Most people don't update Web sites via makefiles/scripts/whatever that can easily be extended to zip for them. A lot of people use FrontPage or the Windows Web Publishing Wizard - good luck explaining how to run gizp. Remember - most users of Apache are not software develoeprs. - a LOT of third party tools make it really hard to insert gzip output filters in the right place. Last I checked Tomcat 3.X did not support this without hacking at their classes.Other JSP engines are even worse. Don't even start thinking about some of the more pricey site-management suites. I haven't studied either of these two modules in depth, but the lack of a simple negotiate on gzip encoding for text/html option has been a major flaw in most (all?) Web servers to date. Putting one of these in the default Apache distribution would be a wonderful thing. - Danny
Re: [PATCH] Add mod_gz to httpd-2.0
On Saturday 01 September 2001 20:10, Cliff Woolley wrote: Taking a step back from gz for a moment, and speaking in general: On Sat, 1 Sep 2001, Ian Holsman wrote: 3rd party modules are invisible to most people, I'll agree with that statement... we can tell ourselves that it's okay to push off modules onto third-party distribution, but the fact is that if it doesn't come as a standard module, people are much less likely to go get it unless they have absolutely no other choice because they either are too lazy, don't know it exists, or fear its stability/security because it's third-party. Perhaps modules distributed through official httpd subprojects are more visible/more trusted, but we don't really know one way or the other on that front yet. I can agree with this, but this is something we need to fix. There are many ways to fix it. Fixing modules.apache.org would be a very good first step. Putting every module into the core is NOT the answer to this problem. IMNSHO, Apache should be a minamilistic web server. If we don't need it in the core, it shouldn't be there. Personally, I would remove mod_dav from the server too, because it doesn't implement part of RFC2616. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [PATCH] Add mod_gz to httpd-2.0
On 2001-09-01 at 18h19, possibly To [EMAIL PROTECTED] et al., the keyboard of Ryan Bloom chattered: 3) I don't believe that we should be adding every possible module to the core distribution. I personally think we should leave the core as minimal as possible, and only add more modules if they implement a part of the HTTP spec. I strongly disagree with that concept. Incredibly strongly. :-) I think module inclusion eligibility should be based on utility and support, and not on anything as limited as protocol relativity. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: [PATCH] Add mod_gz to httpd-2.0
On 2001-09-01 at 20h50, possibly To [EMAIL PROTECTED] et al., the keyboard of Ryan Bloom chattered: Putting every module into the core is NOT the answer to this problem. True. IMNSHO, Apache should be a minamilistic web server. IMNSHO, strong disagreement. It should be able to be configurable as minimalist, but that is *not* synonymous with shipping with a minimal set of modules. If we don't need it in the core, it shouldn't be there. Again, strong disagreement. Assuming that by 'core' you mean 'standard tarballs and install packages downloadable from apache.org.' -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
