You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2003/06/26 17:57:07 UTC
DO NOT REPLY [Bug 10385] -
SSI-Servlet produces invalid character encoding information
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
t.kitynski@11interactive.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |WORKSFORME
------- Additional Comments From t.kitynski@11interactive.com 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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: DO NOT REPLY [Bug 10385] -
SSI-Servlet produces invalid character encoding information
Posted by Earthlink Abuse Department <ab...@abuse.earthlink.net>.
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 abuse@abuse.earthlink.net,
abuse@earthlink.net, abuse@mindspring.com, abuse@netcom.com,
or abuse@onemain.com.
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
>t.kitynski@11interactive.com changed:
> What |Removed |Added
>----------------------------------------------------------------------------
> Status|REOPENED |RESOLVED
> Resolution| |WORKSFORME
>------- Additional Comments From t.kitynski@11interactive.com 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: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org