Hi!
News: http://signlanguageforbaby.com/qyib/page.php
toki...@aol.com
> Mark Nottingham wrote...
>
> On 02/06/2010, at 9:00 AM, toki...@aol.com wrote:
>
> > > Sergey wrote...
> > > That's new to me that browsers don't cache stuff that has Vary only on
> > > Accept-Encoding - can you post some statistics or describe the test you
> > > ran?
> >
> > Test results and
> Paul Fee wrote...
>
>> Bryan McQuade wrote:
>> Are there any cases where it's important for ap_pass_bridgade to pass
>> on an empty brigade? Doesn't sound like it, but since this is a core
>> library change I want to double check.
>
> When handling a CONNECT request, the response will have no bod
> Bryan McQuade wrote...
>
> thanks! it is really great that you did this investigation.
You're welcome, but I wouldn't really call that an 'investigation'.
More like just a quick 'observation'.
> RE: checking to see if in cache, try typing the URL into the nav bar
> and hitting "enter" rather t
Well, FWIW, I got curious about what the state of affairs is TODAY
with this 'Vary: Accept-Encoding' deal and whether or not certain
'modern' browsers will or won't actually CACHE the responses... so I took
a few minutes and just did some simple tests with what I had available
here in front of me
Let me preface ALL the remarks below with TWO statements...
1. I haven't done any research on these HTTP based Client/Server compression
topics in quite some time. It is all, essentially, 'ancient history' for me
but it still amazes me that some of the issues are, so many years later,
still bei
> Sergey wrote...
> That's new to me that browsers don't cache stuff that has Vary only on
> Accept-Encoding - can you post some statistics or describe the test you ran?
Test results and statistics...
Apache DEV forum...
http://www.pubbs.net/200908/httpd/55434-modcache-moddeflate-and-vary-user-a
> web sites are loading too slow for pipes and web-server power that we have.
The key phrase there is 'that WE have'.
YOU need to tune YOUR configs to match what YOU have.
ANYONE who uses Apache can/should/must do that.
That's how that works.
The discussion at this moment is what 'default' confi
>> Don't forget the ongoing issue that if you ONLY vary on 'Accept-Encoding'
>> then almost ALL browsers will then refuse to cache a response entity LOCALLY
>
> Really? That sounds bizarre! Do you have a reference for it?
>
> Nick Kew
Apache DEV forum...
http://www.pubbs.net/200908/httpd/55434-
> There is zero reason for us to avoid putting deflate into the default
> configuration.
Sorry. There ARE (good) reasons to avoid doing so.
I'm the one who wrote the FIRST mod_gzip module for Apache 1.x series
so you would think I'd be a strong advocate of 'auto-enablement' by default,
but I am
Don't forget the ongoing issue that if you ONLY vary on 'Accept-Encoding'
then almost ALL browsers will then refuse to cache a response entity LOCALLY
and the pain factor moves directly to the Proxy/Content Server(s).
If you vary on 'User-Agent' ( No longer reasonable because of the abuse
of tha
> Mario wrote...
>
> Dear Kevin,
> So, I want to know who are (the) developers that more contributed
> (contributed more) with (to) the Apache project in period:
> - Release 1.3 (1997 and 1998)
> - Release 2.0 (1999 and 2000)
> - 2001 and 2002
> - 2003 - 2005.
> Did (Do) you understand me?
Now,
Mario...
If you would get someone in your department who knows the English
language a little better to rewrite the request you might get a little
more traction.
I THINK I can 'decipher' what the heck you are asking but not
well enough to risk a response.
Yours
Kevin Kiley
PS: A 'psychometric
> Brian Akins of Turner Broadcasting, Inc. wrote...
>
> We are moving towards the 'if you say you support gzip,
> then you get gzip' attitude.
There isn't a browser in the world that can 'Accept Encoding'
successfully for ALL mime types.
Some are better than others but there are always certain
> William A. Rowe, Jr.
>
> I think we blew it :)
>
> Vary: user-agent is not practical for correcting errant browser behavior.
You have not 'blown it'.
>From a certain perspective, it's the only reasonable thing to do.
Everyone keeps forgetting one very important aspect of this issue
and that i
Ah... the good 'ol days.
-Original Message-
From: Bill Stoddard
To: dev@httpd.apache.org
Sent: Wed, 26 Aug 2009 06:45:11 -0400
Subject: Re: Analysis of the Apache web server code repository
toki...@aol.com wrote:
> I knew Trawick was a slacker most of the time.
> Now there's cool pie
Ah... the good 'ol days.
-Original Message-
From: Bill Stoddard
To: dev@httpd.apache.org
Sent: Wed, 26 Aug 2009 06:45:11 -0400
Subject: Re: Analysis of the Apache web server code repository
toki...@aol.com wrote:
> I knew Trawick was a slacker most of the time.
> Now there's cool pie
I knew Trawick was a slacker most of the time.
Now there's cool pie charts and movies to prove it.
ROFL
Hmm... why do I get the feeling this tool's real usage
is so that IT managers can see who they can 'let go'?
Kevin Kiley
-Original Message-
From: Jeff Trawick
To: dev@httpd.apac
Ray...
Can you send me just the part of your httpd config that governs this
transaction and the redirect to the IIS server? I really would like to
reproduce this here. The moment I can actually make it happen I have
tools in place that will show exactly WHEN/WHERE it's happening (not
gdb. I do
Ray...
Can you send me just the part of your httpd config that governs this
transaction and the redirect to the IIS server? I really would like to
reproduce this here. The moment I can actually make it happen I have
tools in place that will show exactly WHEN/WHERE it's happening (not
gdb. I do
> Believe I may have this working now.
>
> The Treo was sending its Host header as follows:
>
> Host:
>
> (Note the lack of space betwen the colon and hostname.? This probably
> isn't valid but was corrected by Apache as it proxied the request on to
> IIS.? However, maybe the initial invalid heade
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 imitate
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 mod_pro
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 carrie
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
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
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 f
> 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
> 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
> 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 th
It is, in fact, possible to do what you are trying to do but before
anyone tells you how, in public, do you mind expaining, in public,
what the heck you are actually trying to do here?
What's in the posted body and why does it need to become
the "secret (encrypted) request"?
In a message date
> 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
> 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
>
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 ca
> 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
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 3:
> 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 f
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 timin
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 "where
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 arch
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 T
> 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 c
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
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
> 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
> 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
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 shou
Is this just a code dump... or are the Covalent authors promising to
support it and help adapt it to ( Non-Covalent Apache ) needs?
There's already an awful lot of Covalent sponsored code in Apache 2.0
that was 'abandoned' by the original authors.
I believe any code submission to Apache requ
>> 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
> 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 th
>> 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 agr
>> 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
> 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 cle
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 32-bits
> 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 hea
> 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 '
>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
> 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
> 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 foll
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. Ap
> 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 ca
> [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 bot
> 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...
>
>
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
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.
>
>
> 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 lik
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 goo
> 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 unc
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 any
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
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 face?
> 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 oppose
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 CURRE
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 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 RE
>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 wa
>> 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 encod
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
> [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
>> 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
>
> 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.
>--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 worki
>> 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 m
>> 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'
> 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.3
In a message dated 11/29/2001 10:23:47 AM Pacific Standard Time,
[EMAIL PROTECTED] writes:
> > Does the output of mod_deflate have a GZIP and/or ZLIB header on it, or
not?
>
> > Even those 2 headers are NOT the same but that's yet another story.
>
> Correct. deflate is the algorithm. def
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
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
>
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 Pa
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
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
In a message dated 11/28/2001 10:10:50 PM Pacific Standard Time,
[EMAIL PROTECTED] writes:
> On Thu, Nov 29, 2001 at 12:45:18AM -0500, [EMAIL PROTECTED] wrote:
> >
> > Since when do things that have already been
> > voted on just suddenly 'disappear' from the
> > official Apache STATUS fil
In a message dated 11/28/2001 9:56:16 PM Pacific Standard Time,
[EMAIL PROTECTED] writes:
> On Thu, 29 Nov 2001 [EMAIL PROTECTED] wrote:
>
> > Since when do things that have already been
> > voted on just suddenly 'disappear' from the
> > official Apache STATUS file(s)?
>
> It didn't di
Since when do things that have already been
voted on just suddenly 'disappear' from the
official Apache STATUS file(s)?
The section regarding the inclusion of Ian's 'mod_gz'
and the consideration of 'another candidate'
has suddenly VANISHED from the Apache 2.0
STATUS file without any discussion
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 b
In a message dated 01-09-24 00:37:41 EDT, Justin wrote...
> > The only real question is what happens when readbytes is -1 - a
> > higher-level filter explicitly asks for everything. We'd then do a
> > blocking read for the entire socket until it is exhausted. I think
> > the current code wo
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
[snip]
> > Kevin Kiley wrote...
> >
> > That call to mod_gzip_npp() ( Null Pointer Protection ) that remains
> > in the non-debug code was actually an oversight. I have never actually
> > seen the 'r->uri' pointer cause a segfault inside any standard Apache
> > module user-exit, hook, or filt
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 se
Attached is the full 'story-telling' debug version of
mod_gzip.c for Apache 2.x series Servers.
It's the same exact code as the previous non-debug
submission but this one has an interesting ( and
informative ) full 'story-telling' style debug format.
Something tells me you won't be interested in
1 - 100 of 142 matches
Mail list logo
