In a message dated 11/13/2003 12:53:42 PM Central Standard Time, [EMAIL PROTECTED] writes:
By the by...
Covalent signs my paycheck.
And if you look at 1.3, you'll see that I've been pretty
key on staying on top of it.
Kind of blows away your theory, don't it?
Nope
Hi Bill...
This is Kevin...
William Rowe wrote...
We value individual contributions here, not
corporate affiliation.
We means ASF, right?
If so... then I think you just nailed the whole point
of this thread, if I am reading the original poster's
concerns correctly.
There doesn't CURRENTLY
William Rowe wrote...
...Ignoring for a moment the 9.13% of Apache servers that don't
reveal their version whatsoever, ang ignorning rounding errors,
3.57% of the servers out there use some 2.0 version of Apache,
so that 6% of Apache servers (identifying themselves)
run 2.0 as opposed to
Geez... it's nice to discover everybody hasn't just dropped dead!
I see a lot of healthy 'things to do' coming out of this
thread that could inject a lot of life back into the
development... which is what the various threads the past
few days have all been about.
Action items?...
Facts to
Last benchmarks I have currently are quite old.
I think the last time I ( just a USER of Apache ) did
any serious benchmarking was 2.0.40 or something...
but the results were right inline with what Rasmus
just posted.
Apache 2.0 pre-fork was a pig compared to Apache 1.3 prefork.
If I get some
Fantastic!
So Rasmus has just uncovered some 'other' problem then
which means (only) mod_perl is a pig on 2.0 or something?
I guess that's better than the core being the problem.
I'd like to see this get put to bed once and for all and eliminate
it from the 2.0 migration discussion(s).
Got
You are right, apache 2.0 pre fork is apache 1.3 prefork...
Maybe. Maybe not. My 'FACT?:' header had a QUESTION MARK there.
Just in the last 4 or 5 messages on this thread the actual
reality has become even more obfuscated.
Rasmus seems to be saying it's a pig... but maybe he's
simply
Hi Colm...
Slainte!...
Cead mile failte romhat!
Go raibh maith agat!
Wow... I believe everything you are saying... and
please don't take this the wrong way... but I'm not
sure a test that only runs for 1.1 second and 1000
requests with 100 clients being launched ( on the
same machine? ) is a
Hmmm... What I'm really looking for is a response
header or some such that I can set in my JSP page or servlet in Tomcat to
indicate that the response should be left alone
Jess Holle
I assume you want to be able to add a response header from your
back-end that looks something like
In a message dated 3/30/2004 8:06:52 AM Central Standard Time, [EMAIL PROTECTED] writes:
Hi to all,
One of my customers is trying to use to an Apache 2.0.47 using mod_deflate.
Its HTTP implementation works with Apache 1.3.x and mod_gzip but
not with Apache 2.0.47 and mod_deflate.
The PHP
Hi Henri...
Kevin again...
Willing to try and help, Henri... but you've got to give us
something to go on here.
You are asking for crystal-ball debug.
The job doesn't pay enough for that.
Peter Cranstone wrote...
What about trying mod_gzip with Apache 2.x?
That would at least tell them
May be also something related with transfer and chunk.
Perfectly possible.
Stay tuned
Glued to the TV at this point.
Yours...
Kevin
In a message dated 3/30/2004 10:22:28 AM Central Standard Time, [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Hi Henri...
Kevin again...
[EMAIL PROTECTED] wrote...
Hi to all,
A new question to HTTP / RFC gurus.
A customer has developped a custom PHP HTTP client,
using HTTP 1.0 and compression.
That's like mixing Vodka and Beer... something could
easily puke... but OK... I hear ya...
This HTTP client compress both
Roy T. Fielding wrote:
I do wish people would read the specification to refresh their memory
before summarizing. RFC 2616 doesn't say anything about cookies -- it
doesn't have to because there are already several mechanisms for marking
a request or response as varying. In this case
Vary:
Hi Neil...
This is Kevin Kiley...
Personally, I don't think this discussion is all that OT for
Apache but others might disagree.
"Vary:" is still a broken mess out there and if 'getting it right'
is still anyone's goal then these are the kinds of discussions
that need to take place SOMEWHERE.
Neil wrote...
Thanks again Kevin for the insight and interesting links. It seems to me
that there are basically three components here: My server, intermediate
caching proxies, and the end-user browser. From my understanding of the
discussion so far, each of these can be covered as follows:
William Rowe wrote...
I'd worked with some interesting java and cgi code which implements
proxy behavior, as opposed to using a compiled-in module such as
mod_proxy. In order to properly pass on the Server: and Date: headers
(which are owned by the origin server), this patch tests for the
On Tue, 22 Jun 2004, Peter J. Cranstone wrote:
Thanks... we're currently testing a new version of mod_gzip called
mod_gzip64i
For the record, I've fixed the problem.
Super!
It was a failure to support some of the compression flags.
Now I'll have to (side?)port it into a CVS version of
Brian Akins wrote...
Serving cached content:
- lookup uri in cache (via md5?).
- check varies - a list of headers to vary on
- caculate new key (md5) based on uri and clients value of these headers
- lookup new uri in cache
- continue as normal
Don't forget that you can't just 'MD5' a
Brian Akins wrote...
[EMAIL PROTECTED] wrote...
Brian Akins wrote...
Serving cached content:
- lookup uri in cache (via md5?).
- check varies - a list of headers to vary on
- caculate new key (md5) based on uri and clients value of these headers
- lookup new uri in
In other words, Henrik has it right. It is our responsibility to
assign different etags to different variants because doing otherwise
may result in errors on shared caches that use the etag as a variant
identifier.
Henrik is trying to make it sound like it is all Apache's fault.
It is not.
Let me preface all comments by saying that I AGREE with BOTH
Roy and Henrik... If Apache is sending the same exact (strong)
ETag value for both a compressed and an identity variant of
the same entity... then, according to current RFC content,
that is broken behavior and it should be fixed.
You
Justin wrote...
No - this patch breaks conditional GETs which is what I'm against.
See the problem here is that you have to teach ap_meets_conditions()
about this. An ETag of 1234-gzip needs to also satisfy a
conditional request when the ETag when ap_meets_conditions() is run is
1234.
And please stop lying about Squid.
C'mon Henrik. No one is intentionally trying to LIE about Squid.
If you are referring to Justin quoting ME let me supply a big
fat MEA CULPA here and say right now that I haven't looked
at the SQUID Vary/ETag code since the last major release
and I DO NOT KNOW
I wrote about this last week, on dev@httpd.apache.org, with a thread whose
subject
was Introducing mod_openpgp:
Yes, I saw that.
It was your new question about Posting a Secret request and then trying
to re-dump it into Apache as a Trojan Horse that had me confused.
Is this the way you
That's why I thought bringing the concept over here was a good idea.
I'm finally getting some constructive criticism!
It's an interesting idea. There have been years of work put into making
HTTP and Apache extensible for ideas just such as this one and regardless
of what anyone thinks of
Arturo wrote...
Thanks for taking the time to discuss this with me.
I really appreciate it.
I was able to read a whole pgp-encrypted request,
even a large 12+MB one using my code. I read the
content-length header, then read up to that quantity of
bytes, saving the brigades to a context
I'm doing some testing here on the latest build from trunk.
Will let you know ASAP whether this is going to be possible
from solely within a connection input filter or whether you will
need other hooks to pull it off.
In the meantime... if someone else is more familiar with connection
input
I'm not proposing a solution but just pointing out that if this discussion
is going to come up once again that even the latest, greatest versions
of one of the most popular browsers in the world, Microsoft Internet
Explorer, will still REFUSE TO CACHE any response that shows up
with a Vary: on
You are the CNN guy, right?
Of your 30 percent... is there an identifiable User-Agent
that comprises a visible chunk of the requests?
If so... what is it?
Yours...
Kevin Kiley
In a message dated 8/27/2007 10:09:33 AM Pacific Standard Time,
[EMAIL PROTECTED] writes:
On 8/27/07 12:34 PM,
This has been discussed many times before and no one
seems to understand what the fundamental problem is.
It is not with the servers at all, it is with the CLIENTS.
What both of you are saying is true... whether you "Vary:"
on "Content-encoding" and/or "User-agent" or not... there
is a risk of
Igor Sysoev wrote
Actually, with MSIE 5.5+ appearance the chances that client can not
decompress the response from downstream cache have increased.
If MSIE 5.5 is configured to work via proxy with HTTP/1.0, then
MSIE will never send "Accept-Encoding" header, and it would refuse
the
Aw shucks... dad... you never let us have any fun.
ROFL
Kevin
Hmmm... HTTP/1.1 PGP based TLS mechanisms under Itanium?
Interesting ( and OT ).
In a message dated 11/9/2005 2:45:13 PM Central Standard Time, [EMAIL PROTECTED] writes:
Folks, somehow this thread diverged from HTTP/1.1 PGP based
In a message dated 11/9/2005 4:12:50 PM Central Standard Time, [EMAIL PROTECTED] writes:
Bill wrote...
So rather than spin off-topic threads, where's the discussion of taking
something that exists, such as se-linux, and actually leveraging security
features of more evolved security
As someone who knows all of the Windows build platforms well...
my 2 cents jives with your decision, Bill.
Using MSVC 6.0 at this point and keeping the makefiles
is the only 'sane' thing to do at this point.
There are ISSUES with just about any of the newer platforms
including the obvious
There is no such thing as an intermediate proxy that has any kind
of 'filtering' going on that won't, on some occasions, need to 'buffer'
some data. I believe even mod_include will 'wait' for tags to resolve
if they split across buffers.
The real questions to ask is...
Why is the proxy timing
Roy wrote...
The sane solution would be to convince the US government to remove encryption from the export control list, since that regulation has been totally ineffective. That is not likely to happen during this administration, though, and I don't think the ASF is allowed to lobby for it
I wouldn't push the "Apache" thing.
Truth is... a letter could show up at any moment from lawyers
of the Apache Nation regarding the name usage.
Might even be way overdue.
I wouldn't "go there" and draw attention to the issue at all.
Yours...
Kevin Kiley
In a message dated 7/28/2006
Roy is right...
Willy-nilly throwing casts on data objects just to satisfy some
anal-retentive urge to not see any warnings appearing during a
compile is the absolute WRONG thing to do when it comes
to porting 32-bit code to 64-bit platforms.
The situation is NOT as simple as it was when
For example, we had a problem report on #apache a couple of days ago
which turned out, after considerable investigation, to be the result
of a single host ip issuing hundreds of request connections in a few
minutes. Whether this was a deliberate attack or simply a buggy
client is not clear
In the case you just mentioned... it is going to take
a special 'filter' to 'sense' that a possible DOS
attack is in progress. Just fair amounts of 'dataless'
connection requests from one or a small number of orgins
doesn't qualify. There are plenty of official
algorithms around now to
You MUST have SOMETHING that knows the difference
or you don't have DOS protection.
Also... if you wait all the way until you have a 'log' entry for
a DOS in progress then you haven't achieved the goal
of sensing them 'at the front door'.
I don't set myself that goal. I agree that it's
At 10:26 AM 11/22/2004, Cliff Woolley wrote:
On Mon, 22 Nov 2004, Joe Orton wrote:
There's another mod_deflate vs 304 response problem which is being
triggered by ViewCVS on svn.apache.org: when a CGI script gives a
"Status: 304" response the brigade contains a CGI bucket then the EOS,
so
Is there a list of "supported" compilers? I am having to compile using
gcc 2.96 and having some wierdness, but works fine on 3.3. It may be
something else with the box, but just wanted to know if there was an
"official" list.
wasn't the 2.96 one the redhat special version (known to be
In a message dated 8/11/2005 12:42:35 PM Central Daylight Time, [EMAIL PROTECTED] writes:
The code will remove the header file and the disk file; but it also likely needs to go up a 'level' and remove all variants. Because if we get a 404 on a varied entity, it also means that all variants
In a message dated 8/17/2005 2:01:41 PM Central Daylight Time,
[EMAIL PROTECTED] writes:
CacheOverrideHeader Accept-Encoding gzip CacheOverrideHeader User-Agent gzip
This would allow all browsers that send "Accept-Encoding: gzip" and do not match the BrowserMatches to be mapped to the same
Jim J. wrote...
People will not use it unless they can *really* trust a module. Simply expecting people to migrate to it because of the theoretical benefits isn't quite wise, until it has proven itself. The idea is to make it easier for people to have access to a module, use it and test it.
I thnk we all understand what Bill is saying, there is
simpy normal, healthy disagreement. That's good.
Look... every now and then we ALL get the urgre to clean
up the room and move the furniture around and get the
dirty laundry off the floor. Bill thinks modules/experimental
is part of the
Peter J. Cranstone wrote...
Since when does web server throughput drop by x% factor using
mod_deflate?
Jeff Trawick wrote...
I don't think you need me to explain the why or the when to you.
Think again.
Exactly what scenario are you assuming is supposed to
be so 'obvious' that it
Henri Gomez wrote...
- Put part of zlib code in Apache 2.0 source ?
Jeff Trawick wrote...
that is what I suspect to be the safest, easiest-to-understand way...
the build would work like on Windows, where the project file for
mod_deflate pulls in the right parts when building
--On Friday, November 22, 2002 12:03 PM +0100 Henri Gomez
[EMAIL PROTECTED] wrote:
So we should use a copy of mod_gzip compression code in Apache 2.0.
Also as someone involved in mod_jk/jk2, I'll need gzip
compress/uncompress support in Apache 2.0 for a new ajp protocol
I'm working on, so
Justin wrote ( RE: Apache STATUS files )...
Oh, I hate to get more email that I just delete as soon as it comes in
Does anyone actually read these things though?
Yes.
what can happen if I load a module compiled with EAPI flag into a Apache
1.3 without EAPI?? I ask for ditribution of binaries and want to know if
it makes no problems loading EAPI-enabled modules; or if I should
Should work *I think*. It wouldn't work the other way around, of course
(you
[EMAIL PROTECTED] writes:
Stephen Pierzchala wrote:
All:
A question for discussion: should a lower bound be set in mod_deflate?
I just ran a test using the Linux Documentation Project files and found
that some of the files in the test group were quite small, less that 100
bytes. When
FYI: There was a serious brain fart (mine) in the
previous message...
I said...
2. If there's no EOS in the brigade yet you have to assume
more is coming so now it's nut-crackin' time. If the 'minimum
file size' is less than the amount of data already in the first
brigade showing up then
Andre Schild wrote:
[EMAIL PROTECTED] 31.10.2003 23:44:06
On Fri, 31 Oct 2003, Andre Schild wrote:
Please have a look at the following Mozilla bug report
http://bugzilla.mozilla.org/show_bug.cgi?id=224296
It seems that mod_deflate does transfer encoding,
but sets the headers as if doing
My reading of RFC 2616 is that Accept-encoding is only for
content-codings.
You are right. Brain fart on my part.
I am still not sure how the discussion about mod_deflate
has gotten anywhere near Transfer-Encoding:.
mod_deflate is NOT DOING TRANSFER ENCODING.
Was it you that suggested it was
Hi all...
I just have to jump in here since the topic is fascinating...
...and I think there's an opportunity here to review something
that has contributed to the 'slow down' at httpd-dev which
no one has seemed to grasp (yet).
I will call it... The Covalent Factor.
If you look at what has
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
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
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
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'
Greg Stein wrote...
Kevin Kiley asked...
What's it going to take to find out once and for all if
ZLIB can be included in the Apache source tree?
It won't go in. No need for it. That hasn't been well-stated...
It has now, it seems ( finally! ).
Only takes one veto and looks
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'
In a message dated 01-09-05 14:28:29 EDT, you write:
That's wonderful news for users. No longer do they download the tarball,
build it, and enable the features they want, now they trawl the web
looking for this module and that module - assuming they even know the
modules exist in the
In a message dated 01-09-05 14:44:54 EDT, Marc Selmko wrote...
And your motives are entirely altruistic? Why do I have
problems with that? See, if you were going about this right
it would not be RC versus AG, it would be 'us'.
See previous message reagrding 'didactic self-righteous
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
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
In a message dated 01-09-05 17:29:58 EDT, you write:
True enough for everyone. (Except any who might be here as
a job assignment.) The question I asked was, 'Why do you
want to be here?' An answer of 'none of your business' is
perfectly acceptable (though probably not constructive),
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
In a message dated 01-09-05 16:14:01 EDT, Kevin Kiley wrote...
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.
Hello all...
Due to comments made in a private email to
myself and my company from one of your top level
board members this is to inform everyone that we
can stop this nonsense right now because there
will BE no submission of mod_gzip for Apache 2.0
to this group.
It shall remain a ( fully
Hello all...
Due to comments made in a private email to
myself and my company from one of your top level
board members this is to inform everyone that we
can stop this nonsense right now because there
will BE no submission of mod_gzip for Apache 2.0
to this group.
It shall remain a ( fully
Hi Justin...
Kevin Kiley here...
Justin wrote...
FWIW, we're discussing Ian's mod_gz not Remote Communication's
mod_gzip since an Apache 2.0 version of mod_gzip has not been
submitted to the Apache Group for inclusion. -- justin
Jim Jagielski asked...
Can I ask why the rush? Let's
In a message dated 01-09-06 19:30:47 EDT, Justin wrote...
I think this functionality belongs in the core (not as a
sub-project or as a separate standalone module). That's it.
Fair enough. Thanks for the quick reply.
You won't get any argument from me on that point.
I was saying that
In a message dated 01-09-08 01:29:57 EDT, Ian wrote...
looking back at justin's original request.
the code was posted ~1 month ago.
he reviewed it, he thought it was OK.
and asked..
'guys.. should we have this module included?'
a simple enough question.
Yes, it was... ( a
In a message dated 01-09-08 14:34:49 EDT, Justin wrote...
As most of you know (like I haven't said it enough), I'm going to be
out of regular email contact for a few weeks. But, I hope this
enlightens you on my perspective on what should happen before a
GA is released. I look
In a message dated 01-09-08 17:43:15 EDT, Ryan wrote...
I know that there aren't many modules for 2.0 today, but at some
point, everybody who has a module for 1.3 will want to port it to 2.0. I
can currently do that in under one hour for even complex modules.
Changing API's like this
Hello all...
Kevin Kiley here..
I spent the day talking to Dr. Mark Adler ( co-author of ZLIB )
with the specific focus being certain issues that are on the
table here at the Apache forum.
As Peter (Cranstone) and I mentioned in the exchange last week
( but things got lost in the noise )
In a message dated 01-09-10 10:00:09 EDT, Ryan wrote...
All I keep thinking, is that we are trying to spite RC by adding a
different GZ module
Don't worry about it. Let's see if we can make a decision on what is
good for the survival of Apache irrespective of what that means for RC.
In a message dated 01-09-10 12:28:55 EDT, Kevin Kiley wrote...
The following is NOT flamebait. I swear.
It is just an observation that is missing from the discussion.
I am just pointing out that no one has done a really good
code review of mod_gz even if the 'consensus' is to drop
Hello all.
This is Kevin Kiley
As promised...
Below is a cut from the second conversation I had
with Dr. Mark Adler ( co-author of ZLIB ) this weekend
regarding some of the possible legal 'patent' issues that
have been raised ( Ryan, Dirk, others? ) as they might relate
to using ZLIB inside
In a message dated 01-09-15 12:30:13 EDT, you write:
Now they are demanding the change.. Not acked. Anyone
want to take this up with them?
1. If they have already found the problem and fixed it for
themselves where is the house on fire?
2. Tell them to submit a patch just like you tell
In a message dated 01-09-15 15:16:16 EDT, Cliff Wooley wrote...
On Sat, 15 Sep 2001 [EMAIL PROTECTED] wrote:
We decided not to wait any longer for a new BETA.
Attached is the current source code for mod_gzip
for Apache 2.x series. It has been tested
pretty heavily and seems
In a message dated 01-09-15 15:44:43 EDT, Ian wrote...
Coments on coments ( my2c )...
additional comments (my 2c)
* Caching should be removed (there is another caching module there
it should use that), failing that, maybe it should be split out to
a different filter
What caching
In a message dated 01-09-15 16:34:59 EDT, Cliff wrote...
In the heated exchange last week that was one of my specific
questions ( major formatting concerns ) and the specific answer was
that it didn't matter much at this point in time.
If I had thought anyone still cared about
In a message dated 01-09-15 17:23:07 EDT, you write:
[Light comes on] Ahhh... guess I should have looked more closely at
mod_log_config and I would have realized that you can configure it to
write certain notes to the log file. Duh. My fault.
Wasn't the concensus a while back that
In a message dated 01-09-15 19:13:06 EDT, Ryan wrote...
Wasn't the concensus a while back that request_rec-notes should be
removed, because the more efficient 'userdata' functions on r-pool
had made the notes table obsolete?
--Brian
It was 'discussed' but never
In a message dated 01-09-16 15:38:37 EDT, Cliff wrote...
I should have been more explicit. It's not bogus to do a conditional like
the one you just displayed. I thought it was excessive to make it a whole
separate function that's only used in one place. I thought it was bogus
to set
Hello all...
This is Kevin Kiley
In an effort to resolve a pending issue with regards to the
inclusion of code that supports dynamic IETF Content-Encoding
I checked out the whole OS_CODE issue in ZLIB.
If you use the OS_CODE manifest constant in whatever code
you end up with in the source tree
In a message dated 01-10-01 04:37:59 EDT, Greg Stein wrote...
I have been looking and looking at the patch and someone want
to tell me where it checks for TE: which is the only way to
REALLY know how the Transfer-Encoding will end? ( Blank
CR/LF following CR/LF following 0 byte
In a message dated 11/28/2001 10:21:46 PM Pacific Standard Time,
[EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED]
Sent: Wednesday, November 28, 2001 11:45 PM
Since when do things that have already been
voted on just suddenly 'disappear' from the
official Apache STATUS file(s)?
In a message dated 11/28/2001 10:26:28 PM Pacific Standard Time,
[EMAIL PROTECTED] writes:
As you point out, vacations are rough for tracking discussions.
What is the http content-encoding value for this facility? deflate
Ergo, mod_deflate.
'deflate' is not GZIP, it's just PART of
Hello William...
This is Kevin Kiley again...
See comments inline below...
In a message dated 11/28/2001 10:59:26 PM Pacific Standard Time,
[EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED]
Sent: Thursday, November 29, 2001 12:30 AM
In a message dated 11/28/2001 10:21:46 PM Pacific
In a message dated 11/29/2001 3:23:32 AM Pacific Standard Time,
[EMAIL PROTECTED] writes:
William A. Rowe, Jr. wrote:
What is the http content-encoding value for this facility? deflate
Ergo, mod_deflate.
And the name change from mod_gz to mod_deflate was suggested
by Roy,
In a message dated 11/29/2001 3:23:27 AM Pacific Standard Time,
[EMAIL PROTECTED] writes:
As described by Ken? Once again, what would he have to do
with that?
I just happen to be the chap with the cron job that sends
the current STATUS file every Wednesday. I don't maintain it;
Ryan Bloom wrote.
It's being printed now, should be in stores in a week or two.
Congratulations ( I mean it ).
Interesting timing, though.
That means final draft(s) went to publisher on or about
the time that you initiated the release of Apache 2.0
way before it was ready for GA ( 2.0.35
Your posts keep saying The Treo does this and the Treo does
that and likelihood of fixing Treos is 0 percent...
...but I'm a little confused.
What SOFTWARE are we talking about on the Treo.
The Treo is just a handheld. It does what it's told to do.
Are you using one of the carrier's
Ah... okay. Thanks for the clarification.
Sounds you are just stuck in the middle trying
to deal with a broken client. I thought you might
be trying to actually implement the client software
or something.
Sure, you can fix this.
Just get in with a monkey wrench if you have to and force
Well, I thought this one would be easy to spot but it's not.
There's nothing I can do here to reproduce the reported behavior.
I wrote a Perl script client that sends your EXACT ( Palm Treo )
OPTIONS request as you had it documented in the last email.
I also wrote a simple Perl Server to
1 - 100 of 119 matches
Mail list logo
