[OWASP-ESAPI] 2.0 ESAPI Encoder Change Suggestions

Kevin W. Wall kevin.w.wall at gmail.com
Wed Dec 2 00:40:55 EST 2009

Chris Schmidt wrote:
> Is there any reason that we cannot provide both?
> There are certainly cases where an approach like I suggested would be ideal
> (such as with DSL's and the like) but I also agree that in 90% of the cases,
> having ESAPI.encoder().encoderForHTML( stuff ) will be not only sufficient,
> but ideal.
> Under the covers, why couldn't ESAPI.encoder().encodeForHTML( stuff )
> delegate to encoder.encode( EncoderTarget.HTML_DOC, stuff ) or something
> similar. In that case, we appease the K.I.S.S. paradigm while providing a
> rich API when it is needed.
> I personally work with Apache Lucene *alot* and this is the way that the
> Apache guys solved similar problems with text analysis. They provide simple
> implementations of Analysis algorythms out of the box that can be plugged in
> anywhere, but also expose a rich API that allows developers to do just about
> anything they want with text and tokens where requirements necessitate it.
> Thoughts?

Both/and rather than either/or makes sense. I just can't comment on how
feasible or simple it is based on the fact I haven't really studied this
particular section of code very much. To me, it just sounded as though it
were an either/or decision based on Jim's reply to Jeff, so that was what
I was responding to.

Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME

More information about the OWASP-ESAPI mailing list