httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Life is hard, and then you die" <ron...@innovation.ch>
Subject Re: hooks
Date Sat, 08 Jul 2000 06:34:34 GMT
On Thu, Jul 06, 2000 at 09:53:15AM -0400, Jeff Trawick wrote:
> > Date: Wed, 5 Jul 2000 13:12:21 -0700
> > From: "Life is hard, and then you die" <ronald@innovation.ch>
> 
> > Btw., does anybody disagree with changing the update functions in
> > md5 and sha1 to ap_MD5Update_ascii(), ap_MD5Update_binary(),
> > ap_SHA1Update_ascii(), and ap_SHA1Update_binary()? I.e. to better
> > reflect which are ascii and which binary (the ascii forms first
> > translate the characters as necessary to ascii). And similarly
> > for ap_base64. Currently we have ap_SHA1Update() and
> > ap_SHA1Update_binary() in 1.3.
> 
> A. MD5:
> 
> Currently:
> 
>   single call to ap_MD5Init()
>   optional single call to ap_MD5SetXlate()
>   multiple calls to ap_MD5Update()
>   single call to ap_MD5Final()
> 
> Your proposal (I guess):
> 
>   single call to ap_MD5Init()
>   multiple calls to either ap_MD5Update_ascii() or ap_MD5Update_binary()
>   single call to ap_MD5Final()

Yes.

> 1) _ascii is a mis-nomer for this feature; we don't know or care what
>    type of translation is performed (if it is done); since this is
>    content, it could be anything

Agreed - I wasn't thinking too far. So _text would probably be better.

> 2) I like the current API better because once the app sets up the
>    translation properly it doesn't have to have dual paths later
>    (Hmmm... do I call ap_MD5Update_ascii() or ap_MD5Update_binary()?)
> 
> You could get rid of ap_MD5SetXlate() and provide an additional
> parameter to ap_MD5Init() if you want to simplify it.

The problem with the current setup and with ap_MD5Init(ap_xlate,...) is that
they aren't mt-safe. The later could be made so if the ap_xlate is stored
as part of the context, not in a global variable as is done in
ap_SHA1InitEBCDIC. Passing the ap_xlate in _text provides for a little
more flexibility, but I honestly don't know if that's needed or useful.

> B. SHA1
> 
> This is definitely hard-wired for EBCDIC currently.  The API set could
> be changed to be more similar to the MD5 one, but you'll need to
> change more code in the utilities to be EBCDIC-aware.  It is ugly
> either way, but until some app needs a different type of translation
> for SHA1, I think the code savings (and the related smaller amount of
> EBCDIC awareness in Apache) with the current API set is worth the
> ugliness.  #ifdef EBCDIC is pretty ugly to me, and I are EBCDIC for at
> least part of the day.

This brings up a second point that I'm having problems with: if we have
ap_xlate, then why the heck do we have #ifdef CHARSET_EBCDIC everywhere?
We should just be able to pass an ap_xlate everywhere, and if that's
NULL then the ap_xlate_conv_buffer should be a no-op. I don't think that
extra function call and test is going to affect performance noticeably,
considering all the other code in the sha/md5/base64/etc functions.

> C. base64
> 
> no real opinion...  I don't have a notion of how much app-level code
> would get changed (and possibly uglified).  You'll find out soon
> enough.

Basically same as above, i.e. supply _text and _binary versions. Since these
are not multipart operations we have to supply the ap_xlate to the _text.
The only problem is the pr2six table - not sure what to do about it. One
possibility would be to use a cache of pr2six tables, and compute them on
the fly if not in the cache.


  Cheers,

  Ronald


Mime
View raw message