Re: [us...@httpd] Problem with mod_headers ?
Rainer Jung wrote: On 31.12.2008 10:08, André Warnier wrote: Juha Laiho wrote: [...] Thanks, Juha. That helps me think in another direction. Maybe indeed in this case the mod_headers module does not get a chance to modify the response headers, because it is added before the mod_jk module, and mod_jk overrides it. It is worth investigating anyway, since the other solutions I can see are a lot heavier in my case (output filter or trying mod_proxy_ajp). Apache 2 has hooks for modules, but also filters. The hooks allow to interact with request processing at certain stages and the modules decide, whether they allow other modules to be called in the same hook. mod_headers is a filter, which allows to manipulate requests and responses much like servlet filters during the reading and writing of request resp. response. Thus you can use mod_headers to change headers after they are returned by mod_jk. Unfortunately the Content-Type header is a different beast. Inside Apache it is not only a response header, but a more complex data type. You can set a different Content-Type header with mod_headers, but since the internal structure remains unchanged it will be overwritten again by Apache. As a result I see no way to change an existing character set in a Content-Type header. I have tried changing the Content-Type header in a servlet filter under Tomcat. However, that also has the side-effect that the servlet then, for its response, really uses the new character encoding specified in the header, to produce its response. That is not what I want here, because the problem is that the servlet response is already correct (in the iso-8859-2 encoding), it is just that the Content-Type header is incorrect and does not match the real charset of the response. The underlying reason for all that stuff is obscure and OT here, but that is really what happens. See javax.servlet.ServletResponseWrapper. A filter can replace request and/or response with a custom wrapper object. Whenever the servlet then calls a method of the request or response object, your custom object is called. Your custom response wrapper extends the standard one, which itself lets all methods call through to the wrapped response. You can then implement individual methods in a different way. You could for instance overwrite setCharacterEncoding(java.lang.String charset) to set something else, then demanded by the caller (e.g. iso-8859-2 instead of iso-8859-1), and getCharacterEncoding() to return something different, from what you actually set. The filter can inspect e.g. the URL to decide, whether it should wrap the response or not. This mechanism can be used without any changes to the existing webapp code, you only need to add your filter and wrapper to the webapp, and of course add the filter to web.xml. Thanks for your very clear response, Rainer. This will save me a lot of time trying unworkable solutions, such as trying mod_proxy_ajp instead of mod_jk. I also tried a mod_perl connection output filter in the meantime (based on Apache2::Filter::HTTPHeadersFixup), with no more success. Your explanation above makes clear why. To wrap us thus : - with mod_headers or another Apache or mod_perl connection output filter, one *can* modify response headers set by a Tomcat application and returned through mod_jk (or whatever), but the Content-Type header is a special case. It will also be in fact modified by the above, but Apache will in the end override that modification and restore the original Content-Type header, based on some internal information. This has nothing to do with mod_jk itself, it is a generic Apache mechanism for the Content-Type header in particular. - the only viable solution in my case is thus to make sure that the Tomcat servlet issues the correct Content-Type header in the first place. If the servlet itself cannot be modified, then a servlet filter wrapping the response in a javax.servlet.ServletResponseWrapper wrapper would be the way to go. The wrapper should override the methods by which the servlet sets and/or obtains the response encoding. (In my case, the servlet has to keep believing that its response output stream is iso-8859-1, otherwise it does the wrong charset translations from its internal Unicode strings to the 8-bit response stream.) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How can the login page see parameters in the original request?
Do you mean set session attributes? How do you do that from the client side? --- On Wed, 12/31/08, Konstantin Kolinko knst.koli...@gmail.com wrote: From: Konstantin Kolinko knst.koli...@gmail.com Subject: Re: How can the login page see parameters in the original request? To: Tomcat Users List users@tomcat.apache.org, removeps-gro...@yahoo.com Date: Wednesday, December 31, 2008, 5:43 AM 2008/12/30 removeps-gro...@yahoo.com: To hide the existence of the page from robots. --- On Tue, 12/30/08, Pid p...@pidster.com wrote: From: Pid p...@pidster.com Subject: Re: How can the login page see parameters in the original request? To: Tomcat Users List users@tomcat.apache.org Date: Tuesday, December 30, 2008, 6:26 AM removeps-gro...@yahoo.com wrote: Only if certain secret fields and values are present, do I want to generate the login page. They're not really secret if you're passing them as parameters. It sounds like you're trying to over-engineer something, which often results in no security improvements and sometimes introduces flaws. What is your real goal? How about passing them with the Session? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Basic int/char conversion question
From: André Warnier [mailto:a...@ice-sa.com] Subject: [OT] Basic int/char conversion question I cannot change the InputStream into something else Actually, I think you can. If you wrapper the InputStream with an InputStreamReader specifying the desired character set, the rest of the code can continue to use the read() method and check for specific character (rather than byte) values. For example: fromApp = new InputStreamReader(socket.getInputStream(), Charset.forName(ISO-8859-2)); As long as the code is checking for values in the ASCII range (0 - 127) or -1, I believe this will work for you. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Basic int/char conversion question
On Thu, Jan 1, 2009 at 11:13, André Warnier a...@ice-sa.com wrote: Hi. This has nothing specific to Tomcat, it's just a problem I'm having as a non-java expert in modifying an exiting webapp. I hope someone on this list can answer quickly, or send me to the appropriate place to find out. I have tried to find, but get somewhat lost in the Java docs. Problem : an existing webapp reads from a socket connected to an external program. The input stream is created as follows : fromApp = socket.getInputStream(); The read is as follows : StringBuffer buf = new StringBuffer(2000); int ic; while((ic = fromApp.read()) != 26 ic != -1) // hex 1A (SUB) buf.append((char)ic); This is wrong, because it assumes that the input stream is always in an 8-bit default platform encoding, which it isn't. How do I do this correctly, assuming that I do know that the incoming stream is an 8-bit stream (like iso-8859-x), and I do know which 8-bit encoding is being used (such as iso-8859-1 or iso-8859-2) ? I cannot change the InputStream into something else, because there are a zillion other places where this webapp tests on the read byte's value, numerically. I mean, to append correctly to buf what was read in the int, knowing that the proper encoding (charset) of fromApp is X, how do I write this ? Thanks. Another option: Read the bytes into a ByteBuffer, then convert the bytes into a string. You can tell the String constructor which charset to use. -- Len
RE: [OT] Basic int/char conversion question
From: Len Popp [mailto:len.p...@gmail.com] Subject: Re: [OT] Basic int/char conversion question Another option: Read the bytes into a ByteBuffer, then convert the bytes into a string. You can tell the String constructor which charset to use. That would seem to violate one of the specified constraints: I cannot change the InputStream into something else, because there are a zillion other places where this webapp tests on the read byte's value, numerically. whereas using an InputStreamReader would not since its read() method is compatible with that of a plain InputStream. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting Up PHP on Tomcat
michel wrote: I am following the instructions at Using PHP With Tomcat from http://wiki.apache.org/tomcat/UsingPhp and I am ok until I run Makefile and I the following: Command './Makefile' failed with return code 2 and error message ./Makefile: line 1: srcdir: command not found ./Makefile: line 2: builddir: command not found ./Makefile: line 3: top_srcdir: command not found ./Makefile: line 4: top_builddir: command not found ./Makefile: line 5: EGREP: command not found ./Makefile: line 6: SED: command not found ./Makefile: line 7: CONFIGURE_COMMAND: command not found I would love to know what I'm doing wrong! Isn't one just supposed to enter make ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting Up PHP on Tomcat
- Original Message - From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 01, 2009 1:57 PM Subject: Re: Setting Up PHP on Tomcat michel wrote: I am following the instructions at Using PHP With Tomcat from http://wiki.apache.org/tomcat/UsingPhp and I am ok until I run Makefile and I the following: Command './Makefile' failed with return code 2 and error message ./Makefile: line 1: srcdir: command not found ./Makefile: line 2: builddir: command not found ./Makefile: line 3: top_srcdir: command not found ./Makefile: line 4: top_builddir: command not found ./Makefile: line 5: EGREP: command not found ./Makefile: line 6: SED: command not found ./Makefile: line 7: CONFIGURE_COMMAND: command not found I would love to know what I'm doing wrong! Isn't one just supposed to enter make ? ouch, I got that one wrong thanks ... but I can't find make that is supposed to be in the same directory as configure - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting Up PHP on Tomcat
- Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 01, 2009 2:12 PM Subject: Re: Setting Up PHP on Tomcat michel wrote: I am following the instructions at Using PHP With Tomcat from http://wiki.apache.org/tomcat/UsingPhp and I am ok until I run Makefile and I the following: Command './Makefile' failed with return code 2 and error message ./Makefile: line 1: srcdir: command not found ./Makefile: line 2: builddir: command not found ./Makefile: line 3: top_srcdir: command not found ./Makefile: line 4: top_builddir: command not found ./Makefile: line 5: EGREP: command not found ./Makefile: line 6: SED: command not found ./Makefile: line 7: CONFIGURE_COMMAND: command not found I would love to know what I'm doing wrong! For a start, you are hi-jacking an unrelated thread. That usually means that most people will ignore your question. How is a thread I started and called Setting Up PHP on Tomcat hi-jacking?
Re: Setting Up PHP on Tomcat
On Thu, Jan 1, 2009 at 11:22 AM, michel compu...@videotron.ca wrote: ouch, I got that one wrong thanks ... but I can't find make that is supposed to be in the same directory as configure Dunno what makes you think that, but it's wrong -- `make` should be on your system (in your PATH), that's all. -- Hassan Schroeder hassan.schroe...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting Up PHP on Tomcat
- Original Message - From: Hassan Schroeder hassan.schroe...@gmail.com To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 01, 2009 2:38 PM Subject: Re: Setting Up PHP on Tomcat On Thu, Jan 1, 2009 at 11:22 AM, michel compu...@videotron.ca wrote: ouch, I got that one wrong thanks ... but I can't find make that is supposed to be in the same directory as configure Dunno what makes you think that, but it's wrong -- `make` should be on your system (in your PATH), that's all. Ok, thanks for that one! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Basic int/char conversion question
Caldarale, Charles R wrote: From: Len Popp [mailto:len.p...@gmail.com] Subject: Re: [OT] Basic int/char conversion question I note with satisfaction that I'm not the only one laboring away on this day-after, but you're just all going a bit too fast for me and my growing but still limited Java knowledge. I like the idea of wrapping this in an InputStreamReader, but how is this solving my problem ? Suppose I do this : String knownEncoding = ISO-8859-1; // or ISO-8859-2 InputStreamReader fromApp; fromApp = = new InputStreamReader(socket.getInputStream(), Charset.forName(knownEncoding)); int ic = 0; StringBuffer buf = new StringBuffer(2000); while((ic = fromApp.read()) != 26 ic != -1) // hex 1A (SUB) buf.append((char)ic); .. then I'm still appending the same char (really, byte) to my buffer, right ? For example, suppose the byte in question is \xB5 on the fromApp stream. Interpreted as iso-8859-1, this would be the character micro, with Unicode codepoint U00B5, which I would thus append to the StringBuffer (which is, unless I am mistaken, composed of Unicode characters). However, if the fromApp stream really was iso-8859-2, this same byte \xB5 should be interpreted as the Unicode codepoint U013E (LATIN SMALL LETTER L WITH CARON). ( ł ) But by doing buf.append((char) ic) I am still interpreting ic as being, by platform default, ISO-8859-1, thus I am still appending the Unicode codepoint U00B5. Not so ? Or, can I / do I have to now also say : char ic = 0; while((ic = fromApp.read()) != 26 ic != -1) // hex 1A (SUB) buf.append(ic); ?? In other words, in order to keep my changes and post-festivities headaches to a minimum, I would like to keep buf being a StringBuffer. So what I was really looking for was the correct alternative to buf.append((char) ic); which would convert ic from an integer, to the appropriate Unicode character, taking into account the knownEncoding which I know. Does that not exist ? A cursory examination of the webapp code seems to show that the byte in question is only ever compared to either -1 or integers below 127, or characters in the lower ASCII range A-Za-z. But is if (char == some-integer) always valid as a replacement for if (int == some-integer) ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting Up PHP on Tomcat
michel wrote: - Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 01, 2009 2:12 PM Subject: Re: Setting Up PHP on Tomcat michel wrote: I am following the instructions at Using PHP With Tomcat from http://wiki.apache.org/tomcat/UsingPhp and I am ok until I run Makefile and I the following: Command './Makefile' failed with return code 2 and error message ./Makefile: line 1: srcdir: command not found ./Makefile: line 2: builddir: command not found ./Makefile: line 3: top_srcdir: command not found ./Makefile: line 4: top_builddir: command not found ./Makefile: line 5: EGREP: command not found ./Makefile: line 6: SED: command not found ./Makefile: line 7: CONFIGURE_COMMAND: command not found I would love to know what I'm doing wrong! For a start, you are hi-jacking an unrelated thread. That usually means that most people will ignore your question. How is a thread I started and called Setting Up PHP on Tomcat hi-jacking? You didn't start this thread. You replied to an old message and changed the subject. Even though you changed the subject, it remains part of the previous thread. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting Up PHP on Tomcat
- Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 01, 2009 2:51 PM Subject: Re: Setting Up PHP on Tomcat michel wrote: - Original Message - From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 01, 2009 2:12 PM Subject: Re: Setting Up PHP on Tomcat michel wrote: I am following the instructions at Using PHP With Tomcat from http://wiki.apache.org/tomcat/UsingPhp and I am ok until I run Makefile and I the following: Command './Makefile' failed with return code 2 and error message ./Makefile: line 1: srcdir: command not found ./Makefile: line 2: builddir: command not found ./Makefile: line 3: top_srcdir: command not found ./Makefile: line 4: top_builddir: command not found ./Makefile: line 5: EGREP: command not found ./Makefile: line 6: SED: command not found ./Makefile: line 7: CONFIGURE_COMMAND: command not found I would love to know what I'm doing wrong! For a start, you are hi-jacking an unrelated thread. That usually means that most people will ignore your question. How is a thread I started and called Setting Up PHP on Tomcat hi-jacking? You didn't start this thread. You replied to an old message and changed the subject. Even though you changed the subject, it remains part of the previous thread. Ok, I get it and thanks for the explanation! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Basic int/char conversion question
On Thu, Jan 1, 2009 at 14:39, André Warnier a...@ice-sa.com wrote: I note with satisfaction that I'm not the only one laboring away on this day-after, but you're just all going a bit too fast for me and my growing but still limited Java knowledge. No hang-over here. :-) In other words, in order to keep my changes and post-festivities headaches to a minimum, I would like to keep buf being a StringBuffer. So what I was really looking for was the correct alternative to buf.append((char) ic); which would convert ic from an integer, to the appropriate Unicode character, taking into account the knownEncoding which I know. Does that not exist ? (I'll leave the InputStreamReader explanation to Chuck.) I was guessing that the StringBuffer would soon be converted to a String (which is the usual case). If not … I don't see a simple one-line way to convert one byte to a character in a given charset. It looks like String and CharsetDecoder are the classes you're supposed to use. If there's an easy way to convert a single character, someone please point it out. How about this: Read the bytes as bytes, convert them to a String in the correct charset, and create a StringBuffer from that. Like so: String knownEncoding = ISO-8859-1; // or ISO-8859-2 InputStreamReader fromApp; fromApp = = new InputStreamReader(socket.getInputStream(), int ic = 0; ByteBuffer inbuf = ByteBuffer.allocate(2000); while((ic = fromApp.read()) != 26 ic != -1) // hex 1A (SUB) inbuf.put((char)ic); byte[] inbytes = new byte[inbuf.limit()]; inbuf.get(inbytes); String s = new String(inbytes, knownEncoding); StringBuffer buf = new StringBuffer(s); (I haven't tested this so it might not be correct.) It's not very efficient but it keeps the changes in one place. -- Len
RE: [OT] Basic int/char conversion question
Andre/Len in case the earlier responses did not answer how to receive a CharSet encoded InputStream to a reader suggest implmenting a Reader which will accomodate charset (such as InputStreamReader) http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStreamReader.html InputStreamReader public InputStreamReader(InputStream in, Charset cs) Create an InputStreamReader that uses the given charset. Parameters:in - An InputStreamcs - A charsetSince:1.4 BTW: Int to Char conversion String new_string=new java.lang.Integer(int int_input).toString(); BTW: CharToInt conversion int inta=new java.lang.Integer(String str_input).intValue(); HTH Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Date: Thu, 1 Jan 2009 16:23:05 -0500 From: len.p...@gmail.com To: users@tomcat.apache.org Subject: Re: [OT] Basic int/char conversion question On Thu, Jan 1, 2009 at 14:39, André Warnier a...@ice-sa.com wrote: I note with satisfaction that I'm not the only one laboring away on this day-after, but you're just all going a bit too fast for me and my growing but still limited Java knowledge. No hang-over here. :-) In other words, in order to keep my changes and post-festivities headaches to a minimum, I would like to keep buf being a StringBuffer. So what I was really looking for was the correct alternative to buf.append((char) ic); which would convert ic from an integer, to the appropriate Unicode character, taking into account the knownEncoding which I know. Does that not exist ? (I'll leave the InputStreamReader explanation to Chuck.) I was guessing that the StringBuffer would soon be converted to a String (which is the usual case). If not … I don't see a simple one-line way to convert one byte to a character in a given charset. It looks like String and CharsetDecoder are the classes you're supposed to use. If there's an easy way to convert a single character, someone please point it out. How about this: Read the bytes as bytes, convert them to a String in the correct charset, and create a StringBuffer from that. Like so: String knownEncoding = ISO-8859-1; // or ISO-8859-2 InputStreamReader fromApp; fromApp = = new InputStreamReader(socket.getInputStream(), int ic = 0; ByteBuffer inbuf = ByteBuffer.allocate(2000); while((ic = fromApp.read()) != 26 ic != -1) // hex 1A (SUB) inbuf.put((char)ic); byte[] inbytes = new byte[inbuf.limit()]; inbuf.get(inbytes); String s = new String(inbytes, knownEncoding); StringBuffer buf = new StringBuffer(s); (I haven't tested this so it might not be correct.) It's not very efficient but it keeps the changes in one place. -- Len _ Life on your PC is safer, easier, and more enjoyable with Windows Vista®. http://clk.atdmt.com/MRT/go/127032870/direct/01/
Re: [OT] Basic int/char conversion question
2009/1/1 André Warnier a...@ice-sa.com:
Hi.
This has nothing specific to Tomcat, it's just a problem I'm having as a
non-java expert in modifying an exiting webapp.
I hope someone on this list can answer quickly, or send me to the
appropriate place to find out. I have tried to find, but get somewhat lost
in the Java docs.
Problem :
an existing webapp reads from a socket connected to an external program.
The input stream is created as follows :
fromApp = socket.getInputStream();
The read is as follows :
StringBuffer buf = new StringBuffer(2000);
int ic;
while((ic = fromApp.read()) != 26 ic != -1) // hex 1A (SUB)
buf.append((char)ic);
This is wrong, because it assumes that the input stream is always in an
8-bit default platform encoding, which it isn't.
How do I do this correctly, assuming that I do know that the incoming stream
is an 8-bit stream (like iso-8859-x), and I do know which 8-bit encoding is
being used (such as iso-8859-1 or iso-8859-2) ?
I cannot change the InputStream into something else, because there are a
zillion other places where this webapp tests on the read byte's value,
numerically.
I mean, to append correctly to buf what was read in the int, knowing
that the proper encoding (charset) of fromApp is X, how do I write this
?
1. Using iso-8859-1 does not loose any information. That is, you can later
print this out to iso-8859-1 stream, you will get exactly those 8-bit bytes
of iso-8859-2 as were in input.
If you need correctly Unicode, though, you can convert them by calling
String.getBytes(encoding) and new String(bytes, encoding).
new String(str.getBytes(ISO-8859-1), ISO-8859-2)
2. Well, the above, and all the others' tips I have read in this thread so far
are the right ones. Those are what you should do when you are engineering
and writing a well-made application. That is, you have to go with
InputStreamReader, String, CharsetDecoder APIs and that will take care of
various encodings, including multi-byte ones.
In you case, when you are tailoring some oddly (bad) written specific
application
to your specific environment, and do not expect much, there is a
simple approach:
implement this conversion by using a lookup table.
You will just need some static table of 256 chars and you are done.
For example,
package mypackage;
import java.io.UnsupportedEncodingException;
public class TranslationTable {
private static char[] table;
static {
// static initialization block
byte[] bytes = new byte[256];
for (int i=0; ibytes.length; i++){
bytes[i] = (byte) i;
}
try {
table = new String(bytes, ISO-8859-2).toCharArray();
} catch (UnsupportedEncodingException ex) {
ex.printStackTrace();
//System.exit(1);
throw new Error(Class initialization failed, ex);
}
}
public static char lookup(int i) {
// will throw ArrayIndexOutOfBoundsException if i is -1, but that
should be OK
return table[i];
}
}
and replace
buf.append((char)ic);
with
buf.append(TranslationTable.lookup(ic));
Also, I would replace StringBuffer with StringBuilder, if you are
running in Java 5 or
later, but that is another story.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How can the login page see parameters in the original request?
2009/1/1 removeps-gro...@yahoo.com: Do you mean set session attributes? How do you do that from the client side? a) You can set them in another page (an unprotected one) that is accessed before, or that redirects to this one. b) You can pass your secrets as a cookie, or as a request header. Cookies can be created on the client side. c) You can use RemoteAddrValve and block those clients that should not know about your service. d) You can throw away all the security constraints from web.xml and use alternative approaches, e.g. those that implement a Filter, e.g. securityfilter ([1]), that is ofter mentioned on this list and should be easy to adopt, or some others [1] http://securityfilter.sourceforge.net/ Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Basic int/char conversion question
To Konstantin and all the others who have responded, many thanks for all the tips, specially since this was quite a bit off-topic. I need some time to digest the tips though, and choose the best way according to the code that was dumped in my lap. I must say that I find it a bit curious that Java does not have an easy out-of-the-box method to convert a byte to a char, with a character filter specifier. Something like char mychar = toChar(int,charset) (or int.toChar(charset)) Oh well, maybe Java 7.. To Konstantin in particular : I know that I don't lose information by converting iso-8859-2 (thinking it is iso-8859-1) to Unicode one way, then re-converting this Unicode to iso-8859-2 (re-using the iso-8859-1 filter). I will get the same bytes in the end. The problem is that this is a servlet writing the result to the response object. And if I tell it to use iso-8859-1 for the response, it automatically also sets the response Content-Type to iso-8859-1. Which in this case is wrong, because the browser then gets confused. And as I have found out, it is quite hard to change this Content-Type header after-the-fact. Even a servlet filter won't do it, because by that time the response is committed. Even the front-end Apache can't do it, because it won't let you change the Content-Type header.. So my problem is in reverse : The servlet must set the response output encoding to iso-8859-2, in order to produce the correct Content-Type for the browser. To produce correct iso-8859-2 from the internal Unicode string, this Unicode string must have the proper Unicode chars corresponding to the iso-8859-2 characters I want to output. But the servlet reads those bytes as int's, and does a bunch of internal tests and manipulations on them, without taking into account that they could be anything else than iso-8859-1. For the same reason, I cannot just replace the InputStream by something that would translate these bytes on-the-fly to Unicode chars, because for high iso-8859-2 bytes, it would generate internal codes that do no longer fall into values 0-255, and that may create a problem somewhere deep in code I haven't yet looked at. I think I have to go back to examine that code, and see how often this StringBuffer is being used/manipulated. If not too often, I might replace it by a byte buffer, and do the conversion all at once each time it is being written out. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Basic int/char conversion question
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT] Basic int/char conversion question I must say that I find it a bit curious that Java does not have an easy out-of-the-box method to convert a byte to a char, with a character filter specifier. This would be possible only for 8-bit character sets. Since Java tries to be general, you must feed the converter a stream of bytes, rather than one at a time. If you already have an array of bytes, that can be wrapped in a ByteArrayInputStream and then further wrapped in an InputStreamReader, resulting in proper translation of the bytes to Unicode characters. I know that I don't lose information by converting iso-8859-2 (thinking it is iso-8859-1) to Unicode one way, then re-converting this Unicode to iso-8859-2 (re-using the iso-8859-1 filter). I will get the same bytes in the end. That may be true for 8859-1 and 8859-2, but I suspect it's not true in general. The preferred mappings for a Unicode character in a given encoding may not necessarily be the exact bytes given on input, especially if they've been sent through the wrong converter to begin with. Even a servlet filter won't do it, because by that time the response is committed. It will if you wrapper the response object and not commit the real one until you've set the desired header in the filter. For the same reason, I cannot just replace the InputStream by something that would translate these bytes on-the-fly to Unicode chars, because for high iso-8859-2 bytes, it would generate internal codes that do no longer fall into values 0-255, and that may create a problem somewhere deep in code I haven't yet looked at. I suspect that won't be a problem, unless the code is looking for something in the upper ranges. The example you posted showed it looking at control codes, which are the same in Unicode and any ISO-8859 variant. If the code is looking at high-order bytes, it's seriously flawed already. I still think the easiest thing for you to do is put in the InputStreamReader wrapper, and run your test cases. You should certainly examine the code for any erroneous tests, but those should be corrected rather than extending the existing kludge. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Basic int/char conversion question
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT] Basic int/char conversion question Suppose I do this : String knownEncoding = ISO-8859-1; // or ISO-8859-2 InputStreamReader fromApp; fromApp = = new InputStreamReader(socket.getInputStream(), Charset.forName(knownEncoding)); int ic = 0; StringBuffer buf = new StringBuffer(2000); while((ic = fromApp.read()) != 26 ic != -1) // hex 1A (SUB) buf.append((char)ic); .. then I'm still appending the same char (really, byte) to my buffer, right ? No, it's not the same. It's the proper Unicode equivalent of the input byte (or bytes, for multi-byte character sets), not the original 8-bit value. You're responsible for setting the appropriate character set on InputStreamReader constructor to insure that conversion takes place. But by doing buf.append((char) ic) I am still interpreting ic as being, by platform default, ISO-8859-1, thus I am still appending the Unicode codepoint U00B5. That's not correct. The interpretation occurs on the read() operation on the InputStreamReader, not the cast to a char. The read() already converted the byte according to the specified Charset; if your input is 8859-2, you must use that on the InputStreamReader constructor. Or, can I / do I have to now also say : char ic = 0; while((ic = fromApp.read()) != 26 ic != -1) // hex 1A (SUB) buf.append(ic); That can't ever work, since a char is unsigned, so can never have a value of -1; you will get a compilation error since the result of the read() is an int, not a char. In other words, in order to keep my changes and post-festivities headaches to a minimum, I would like to keep buf being a StringBuffer. Which is exactly why you should use an InputStreamReader, not an InputStream, and not change anything else. So what I was really looking for was the correct alternative to buf.append((char) ic); You're looking in the wrong place; the conversion should occur as the input is being read, not during the append(). A cursory examination of the webapp code seems to show that the byte in question is only ever compared to either -1 or integers below 127, or characters in the lower ASCII range A-Za-z. Excellent; then wrappering the InputStream with an InputStreamReader set to the appropriate character set is *exactly* what you need. But is if (char == some-integer) always valid as a replacement for if (int == some-integer) No; a char is unsigned, which is why all read() methods return an int, not a byte or a char. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Basic int/char conversion question
From: Len Popp [mailto:len.p...@gmail.com]
Subject: Re: [OT] Basic int/char conversion question
If there's an easy way to convert a single character,
someone please point it out.
Not particularly easy, but this should work:
import java.io.ByteArrayInputStream;
import java.io.InputStreamReader;
import java.io.IOException;
import java.nio.charset.Charset;
public class Converter {
byte[] ba = new byte[1];
InputStreamReader isr;
public Converter(String csName) {
isr = new InputStreamReader(new ByteArrayInputStream(ba),
Charset.forName(csName));
}
public char convert(byte b) {
try {
isr.reset();
ba[0] = b;
return (char)isr.read();
} catch (IOException ioe) {
// This can't happen in our situation, but...
return '\0';
}
}
}
The calling program merely has to instantiate a Converter once for the
character set of interest, then call the convert method to translate the byte:
cvt = new Converter(ISO-8859-2);
...
myChar = cvt.convert(myByte);
This of course only works for 8-bit character sets.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Basic int/char conversion question
2009/1/2 Caldarale, Charles R chuck.caldar...@unisys.com: From: Len Popp [mailto:len.p...@gmail.com] Subject: Re: [OT] Basic int/char conversion question If there's an easy way to convert a single character, someone please point it out. Not particularly easy, but this should work: (...) isr = new InputStreamReader(new ByteArrayInputStream(ba), Charset.forName(csName)); (...) isr.reset(); reset() is not implemented in InputStreamReader, as of Sun JDK 6u07 that I have installed, thus you have to make a direct call to ByteArrayInputStream.reset(). Well, it serves the same purpose as TranslationTable class that I have provided earlier. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How can the login page see parameters in the original request?
Most thorough, thanks! --- On Thu, 1/1/09, Konstantin Kolinko knst.koli...@gmail.com wrote: From: Konstantin Kolinko knst.koli...@gmail.com Subject: Re: How can the login page see parameters in the original request? To: Tomcat Users List users@tomcat.apache.org Date: Thursday, January 1, 2009, 3:53 PM 2009/1/1 removeps-gro...@yahoo.com: Do you mean set session attributes? How do you do that from the client side? a) You can set them in another page (an unprotected one) that is accessed before, or that redirects to this one. b) You can pass your secrets as a cookie, or as a request header. Cookies can be created on the client side. c) You can use RemoteAddrValve and block those clients that should not know about your service. d) You can throw away all the security constraints from web.xml and use alternative approaches, e.g. those that implement a Filter, e.g. securityfilter ([1]), that is ofter mentioned on this list and should be easy to adopt, or some others [1] http://securityfilter.sourceforge.net/ Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT] Basic int/char conversion question
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Subject: Re: [OT] Basic int/char conversion question
reset() is not implemented in InputStreamReader
Quite correct; sorry - the revised code would be this:
import java.io.ByteArrayInputStream;
import java.io.InputStreamReader;
import java.io.IOException;
import java.nio.charset.Charset;
public class Converter {
byte[] ba = new byte[1];
ByteArrayInputStream bais = new ByteArrayInputStream(ba);
InputStreamReader isr;
public Converter(String csName) {
isr = new InputStreamReader(bais, Charset.forName(csName));
}
public char convert(byte b) {
bais.reset();
ba[0] = b;
try {
return (char)isr.read();
} catch (IOException ioe) {
// This can't happen in our situation, but...
return '\0';
}
}
}
Well, it serves the same purpose as TranslationTable class that
I have provided earlier.
True, and yours should be more efficient, and could be easily modified to
create an instance for any given character set rather than using a static
table. I think the Converter class above is more easily adaptable to
multi-byte character sets should that ever be of interest.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
