tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Proposal: RequestImpl
Date Wed, 03 May 2000 15:44:25 GMT
>  > 3. The practical way to guess the encoding is to determine
>  > the first language in the 'accept-language' values.
> How is that possible? Do you know any good solutions how to tell
> the encoding from the locale? There's often several charsets suitable
> for each language -- which one of them would you choose?
> Then, at my experience, LOTS of users never set the language
> properly. They just not even aware of the existance of these
> settings, or don't want to bother themselves with this kind of stuff.
> They already have the browser installer, then what do you expect
> them to do? Tune it? No bloody way!

If you really want to support that - you can use the browser header,
maybe extract the OS and probably sometimes you can make a
reasonable guess. For example, some OS are able to understand
UTF encoding.

I don't think tomcat should do the guessing - but we should provide
the way for web sites to plug their own modules.

>  > 4. To convert the encoded character stream to the string, I should not
>  > use 'ByteArrayOutputStream', because allocating 'byte[]' again and
>  > again results in the frequent GC and performance issue.
> Yes, this approach seems to be wasteful a bit. I can present a piece of
> code we're using for the same purpose. Out goal was to get rid of the
> char, String and StringBuffer operations also, the ones which bring
> dynamic memory allocation, such as String concatenation.
> I don't know is this code readable enough or not :), but it is
> working. The processParameters() method is called to process
> the parameters at the first getParameter() call (similar to
> RequestImpl.handleParameters() in Tomcat). As for resources,
> we are happy with just two byte arrays, and no any extra object
> creation at all.

It's similar with what I had in mind, but at the level of tomcat

When a request is received ( either HTTP or AJP ) we'll just
pass the byte[] to the afterRead() hooks, and allow them to
detect the method, etc from byte[].

Same for encoding - after the headers are parsed you can extract
the "guess data", make the guess, and then you'll have a chance
to do the byte[] to char[] for every block.

I'll send more details a bit later, I have to clean up the auth part,
then I hope to  have a bit more time.


View raw message