httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: regarding xlate
Date Mon, 29 May 2000 00:01:45 GMT
> Mailing-List: contact; run by ezmlm
> Precedence: bulk
> X-No-Archive: yes
> Reply-To:
> list-help: <>
> list-unsubscribe: <>
> list-post: <>
> Date: Sun, 28 May 2000 15:03:08 -0700 (PDT)
> From: dean gaudet <>
> X-comment: visit for information regarding copyright and
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> X-Spam-Rating: 1.6.2 0/1000/N
> X-UIDL: 8cc463c7f9cf7310932362e5896ca8a3
> i posted a while ago asking questions about why the xlation stuff couldn't
> be done with a layer and i never saw a response... i'm looking at the buff
> code now and i still don't understand why it can't be done with a
> layer.

I thought Martin answered your question or at least attempted to in
one of his last appearances on the list.  Maybe that was just dealing
with where translation of the chunk header should live...  Regardless...

(I won't pretend to be illuminating anything for you, but perhaps if I
explain it as I see it you can show me where I stray from reality.)

The problem I have conceptually when I hear discussions of using a
layer for character set translation (actually, I haven't heard
anything more than a comment here or there regarding character set
translation as a layer) is that it seems like people expect that you
can insert a layer that knows how to translate and then forget about
it, with the inserted layer having some leeway regarding buffering of
data written to it or read from it.  In fact translation has to be
turned on and off and/or switched to a different pair of character
sets at exact byte boundaries in the stream of data from the server to
the client and vice versa, so there is absolutely no leeway in this

> i must be missing something in my quick glance over the code...  when you
> turn on BO_WXLATE or BO_RXLATE then all operations coming from
> bread/bwrite callers are xlated.  therefore it should be a layer.

There is a trivial (and incomplete) form of layering implemented at
the top of buff.  When translation is enabled for output, the
ap_bwrite macro calls a version that translates the caller's buffer wh
Similarly, when translation is enabled for input, the ap_bread macro
calls a version that translates the caller's buffer after calling the
normal routine.  (I have some not-yet-ready code that has one flavor
of bwrite for single-byte translate and a separate flavor for
multi-byte translate.)  If more complete (i.e., implemented for all of
the operations), it would be a layer (or two half-layers, one for
read and one for write) of sorts.

I thought this separate manipulation of read ops vs. write ops was
akin to what you were suggesting in response to some of Martin's

This current layering of sorts could/should be extended to at least
some of the other operations, though I haven't thought of it as a
general problem waiting to be solved and so I haven't considered
flushing out the layer as imperitive.  I certainly wouldn't push to
make it into anything other than hooks to be called for the buff
primitives when APACHE_XLATE is defined.  I see the current
translation support in buff as largely in the style of 1.3 but with
these hooks to clean up some problem areas.

> i consider this a showstopper for 2.0 release... either a better
> explanation as to why it can't be a layer, or add layer support.
> -dean


Jeff Trawick | | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message