Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED]
Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff >DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG >RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT ><http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385>. >ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND >INSERTED IN THE BUG DATABASE. >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385 >SSI-Servlet produces invalid character encoding information >[EMAIL PROTECTED] changed: > What |Removed |Added >---------------------------------------------------------------------------- > Status|REOPENED |RESOLVED > Resolution| |WORKSFORME >------- Additional Comments From [EMAIL PROTECTED] 2003-06-26 15:57 ------- >I haven't found an existing solution to this problem, so I played a bit with >the source and I have working fix for that. >First of all I am not very familiar with the procedure of applying patches to >CVS (I mean I don't know if shall I report it before commiting anything or ask >for a permission or anything else), so I didn't put it into the repository. >Instead I will give out the source and/or binaries if somebody asks. I'll be >happy if the patches would hit the repository anyway. >Okay, here's the trick: now SSIServlet handles two more init-parameters, ie. >defaultInputEncoding and defaultOutputEncoding. First one tells the SSIInclude >command to treat all processed (and included) files as they were written in >this charset (by creating appriopriate readers). The second sets Content- >Type's charset attribute to given value and thus allow to create proper writer. >This forced me to add two methods to SSIExternalResolver interface: >getDefaultInputEncoding and getDefaultOutputEncoding. Both return objects of >the type java.nio.charset.Charset, that hold appropriate charsets. >If happens, that certain included file is in different charset than the rest, >then it's charset can be entered after the file name. I was thinking of using >separate parameter, but it would break NCSA standard, besides <!--#include> >command allows any number of file/virtual parameters, so it would have to be >written like this: <!--#include file="foo.txt" charset="iso-8859-2" >file="bar.txt" charset="iso-8859-1"--> and so on. Well, maybe it's not bad, >but as I've written, it breaks NCSA standard. So instead I've used the same >syntax as in mail headers. So now we shall write: <!--#include >file="foo.txt;charset=iso-8859-2" file="bar.txt; charset = iso-8859-1"--> >a.s.o. I hope this will not break any rule, and I know---it's questionable. >This, however, solves my problems with incorrect output, and if we have all >the files in the same charset, we do not have to use "...;charset=X" >construction (to be honest, I haven't tested the charset stuff just mentioned). >Default encodings works however flawlessly. If anyone is interrested in this >patch, please contact me. If Tomcat developers find this patch usefull or not >too dirty/nasty, then I gladly add my .02 to the contribution. >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
