httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: 1.3.15
Date Mon, 23 Oct 2000 15:18:47 GMT

Mr. Wrowe...

Thanks for your quick and polite response to a legitmate
request for clarification about the real future of the stable
Apache 1.x tree. 

Your 'policy statement' is pretty much exactly what I
( and others ) needed to see because we are out here in
the trenches trying to make plans for the present ( and future ).

I do appreciate it.. but I have a few other ( I think )
pertinent questions. See inline comments below.

In a message dated 00-10-23 12:14:55 EDT, William Rowe writes..

>  From: <>
>  Sent: Monday, October 23, 2000 12:39 AM
>  >
>  > In a message dated 00-10-22 18:52:49 EDT, Jim Jagielski writes
>  >
>  > > Patches only for such a quick turn-around release I think.
>  > > So just the mod_rewrite/Win-32 exec/Netware goodies. :)
>  >
>  > Roger that... but please clarify something for myself
>  > and for others, if you can.
>  >
>  > What is the future of Apache 1.3.x?
>  To try to state this much more politely and optimistically, Apache 1.3.x
>  is at the end of it's new feature stream.  If a new feature doesn't address
>  a security vulnerability or fundemental flaw, it is just going to get 
>  to ask individual members of the httpd project group to take the time to
>  review new ideas.

I need to ask, then, if the HTTP compliance level of the 1.x tree is still
to be considered part of the 'fundamental flaw' category you mention?

There are certainly still things in Apache 1.x that are not fully HTTP 1.1
compliant and I was just wondering if that still matters and would
be part of the 'only certain fixes will be accepted' policy for 1.x and
perhaps justify new 1.x release versions? 


This is taken directly from the HTTP 1.1 specification...


14.3 Accept-Encoding

   The Accept-Encoding request-header field is similar to Accept, but
   restricts the content-codings (section 3.5) that are acceptable in
   the response.

       Accept-Encoding  = "Accept-Encoding" ":"
       1#( codings [ ";" "q" "=" qvalue ] )
       codings = ( content-coding | "*" )

   Examples of its use are:

       Accept-Encoding: compress, gzip
       Accept-Encoding: *
       Accept-Encoding: compress;q=0.5, gzip;q=1.0
       Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

   A server tests whether a content-coding is acceptable, according to
   an Accept-Encoding field, using these rules:

      1. If the content-coding is one of the content-codings listed in
         the Accept-Encoding field, then it is acceptable, unless it is
         accompanied by a qvalue of 0. (As defined in section 3.9, a
         qvalue of 0 means "not acceptable.")

      2. The special "*" symbol in an Accept-Encoding field matches any
         available content-coding not explicitly listed in the header

      3. If multiple content-codings are acceptable, then the acceptable
         content-coding with the highest non-zero qvalue is preferred.

      4. The "identity" content-coding is always acceptable, unless
         specifically refused because the Accept-Encoding field includes
         "identity;q=0", or because the field includes "*;q=0" and does
         not explicitly include the "identity" content-coding. If the
         Accept-Encoding field-value is empty, then only the "identity"
         encoding is acceptable.

   If an Accept-Encoding field is present in a request, and if the
   server cannot send a response which is acceptable according to the
   Accept-Encoding header, then the server SHOULD send an error response
   with the 406 (Not Acceptable) status code.

   If no Accept-Encoding field is present in a request, the server MAY
   assume that the client will accept any content coding. In this case,
   if "identity" is one of the available content-codings, then the
   server SHOULD use the "identity" content-coding, unless it has
   additional information that a different content-coding is meaningful
   to the client.

      Note: If the request does not include an Accept-Encoding field,
      and if the "identity" content-coding is unavailable, then
      content-codings commonly understood by HTTP/1.0 clients (i.e.,

      "gzip" and "compress") are preferred; some older clients
      improperly display messages sent with other content-codings.  The
      server might also make this decision based on information about
      the particular user-agent or client.

      Note: Most HTTP/1.0 applications do not recognize or obey qvalues
      associated with content-codings. This means that qvalues will not
      work and are not permitted with x-gzip or x-compress.


Obviously Apache has not ever been fully 'up to speed' on this section
particuarly regarding all the 'Server SHOULD' RFC directives which
means there is only 'conditional compliance' and not 'full compliance.
I've never seen a 406 from Apache 1.x. even when it SHOULD have been sent.

If patches were submitted to change the 'conditional' to 'full compliance'
would they be accepted?

Not really a 'bug' but that's why I am asking... is there any feeling that
improving any level of HTTP compliance in the 1.x tree would be a
worthwhile thing to do?
>  The majority of group members are hacking into 2.0, experimenting and
>  trying to break it or expand it.  If someone pops up a 2.0 idea, it makes
>  good sense for several of many folks to test and posit an opinion.

Roger that. It's obvious the laser beam is focused on 2.0 but I still
wasn't quite sure if that was an 'all hands on deck for the experimental
for now' kind of a deal or whether it truly represented a 'we ain't going 
scenario. It's been hard to tell. Contributors can have all the plans and
ideas they want... it doesn't matter. It's what the 'committers' are willing
to do that determines what is in the product or not.
>  Nothing goes into the tree without peer review, except perhaps platform
>  specific fixes to OS's that are underrepresented in the group.
>  I know this appears disappointing, but Apache 2.0 is the place for new
>  ideas and creative solutions to grow.  I really doubt we will see an Apache
>  1.4.0, ever.  The http/1.1 implementation is absolutely frozen until 
>  can prove there is a fixable fault.

See above. Would improvements to HTTP compliance levels be 
considered 'fixable faults'?
>  > Will the addition of new features and modifications to the
>  > 1.3.x stable series ever be taken seriously or is Apache 1.3.x
>  > really just 'Dead Man Walking' at this point?
>  No, it's a mature man who rarely needs medical attention, and is living
>  out his live quite nicely, thank you.  But he can't get into Slims, the
>  bouncer is gonna stop him at the door.

If 'Slims' is then I see what you mean... but
I'm not quite clear who the 'bouncer' is? One particular person or
all Apache CVS committers in general?
>  > Everyone is so wrapped up in trying to get 2.0 MPM to Beta that
>  > this issue has been lying on the table for some months now
>  > and no one with committ status at Apache has ever really
>  > given a good answer. Contributors can submit all they want.
>  > Those with committ status and what they will or will not do
>  > are the ones running the show.
>  >
>  > Will all future 1.3.15 or .16 or .xx releases of Apache be
>  > just 'bug fixes only'?
>  Not necessarily.  But you need 3 +1's to move forward with anything
>  (and no -1's with technical justification).  The httpd.d conf directory
>  idea was new, it got in.  It simply had enough testers/advocates.

Okay. Then patches will at least be submitted to change Apache 1.x 
series support for 'Accept-encoding:' from conditional HTTP compliance
to full HTTP compliance and I guess we will see what happens.
>  > You realize, of course, that full widespread use of Apache
>  > 2.0 if/when it even becomes available is probably years away
>  > so I ( and others ) would like to know what the 'official' ASF
>  > Apache Server Group take is on the future of the stable
>  > Apache 1.3.x series.
>  Of course.  1.3.x users don't WANT their server changing, it's working
>  very nicely.  

I'm not sure who you've been talking to. There are still plenty of things
that 1.3.x users 'want'. At least that's what I see every day out here
in the trenches. Many could care less about the MPM model(s)... the
performance is already just fine and dandy as far as they are concerned.

They just want things that don't work to work and new things added to 
make it work better. The idea of abandoning the 'stable' version for the 
elusive and un-tested MPM just to get something new going is still
a bit of a scary idea 'out here in the trenches'.

> > When they look for exciting new features, then 2.0 awaits.

and awaits... and awaits... and awaits... Part of my point.
I am sure it will get there.
I am sure it will achieve stability.

I am sure that when the final design is 'stable' it will be easier to jump
in and help make it even more stable. I am sure many coders are waiting for
things to settle down and then more people will be able to understand
the plethura of new concepts in 2.0 and be able to help. 

When does the basic design level 'lock and load' come? Soon?
It's almost 'next year' (again).

In the meantime... I was just trying to probe for policy regarding the
known STABLE version and the chance to get any new releases of it.

Obviously I am not one of those who has found a way to make a full
time paying job out of working on a public domain server project so I live
in that world where the only contributions I can make are when the
full-timers say things are 'ready' and/or 'possible' and the guidelines
for coding to new specs and the 'policies for submissions' are clearly 
defined. I hope you understand. 

Thanks again for your time and your patience. I know you are a busy man.

Kevin Kiley
CTO, Remote Communications, Inc. - Free IETF Encoding Server - Free Enhanced ApacheBench - Free Apache Content 
Acceleration module

View raw message