[ 
https://issues.apache.org/jira/browse/CLK-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011820#comment-13011820
 ] 

Bob Schellink commented on CLK-757:
-----------------------------------

Couple of notes on the underlying issue. In Servlet 2.3. the 
HttpServletResponse doesn't support the method setCharacterEncoding. Instead 
the charset is set through setContentType by adding the 'charset' header to the 
contentType value. The problem arrise because Page.getConentType returns both 
the contentType and the charset. ActionResult on the other hand provides 
supports two separate properties for contentType and charset. ActionResult 
doesn't realize that the Page already specified the 'charset' header through 
the Page.contentType value and adds the charset to the response a second time. 
To fix we should upgrade to Servlet API 2.4 (2.3 is fairly outdated) which 
added a setCharacterEncoding method to HttpServletResponse. We could then add a 
Page#getCharacterEncoding method as well aligning it with the Servlet API and 
making it clearer what each method should do.

> duplicate Content-Type Response header on AJAX requests
> -------------------------------------------------------
>
>                 Key: CLK-757
>                 URL: https://issues.apache.org/jira/browse/CLK-757
>             Project: Click
>          Issue Type: Bug
>          Components: extras
>    Affects Versions: 2.3.0-RC1
>         Environment: jetty 6+
>            Reporter: Curt
>
> Hi,
> I recently upgraded to click 2.3.0-RC1 and now all of my components
> that extent the AutoCompleteTextField class have stopped working in
> Jetty (still works in Tomcat though).  I don't believe this is Jetty's
> fault.  Here is the response header sent on an AJAX call.  Note the
> duplicate "charset" attribute.  This header looks the same in tomcat
> or Jetty, I think that Tomcat just handles incorrect headers more
> robustly.  I've tried adding a servlet filter reset the encoding type,
> but that did not resolve the unsupported encoding error I see in
> Jetty.
> Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
> Content-Type:text/html; charset=ISO-8859-1; charset=ISO-8859-1
> Expires:Thu, 01 Jan 1970 00:00:00 GMT
> Pragma:no-cache
> Server:Jetty(7.2.0.v20101020)
> Transfer-Encoding:chunked
> All of this code worked fine with Click 2.2.0.  Did something change
> in the way headers are handled in Click between versions 2.2.0 and
> 2.3.0-RC1?  Any Ideas?
> Here is a copy of the stacktrace I am seeing in jetty:
> [Click] [error] java.io.UnsupportedEncodingException:
> ISO-8859-1;org.eclipse.jetty.io.RuntimeIOException:
> java.io.UnsupportedEncodingException: ISO-8859-1;
>        at 
> org.eclipse.jetty.io.UncheckedPrintWriter.setError(UncheckedPrintWriter.java:107)
>        at 
> org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:280)
>        at 
> org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:295)
>        at 
> org.apache.click.ClickServlet.handleAjaxException(ClickServlet.java:1972)
>        at org.apache.click.ClickServlet.handleException(ClickServlet.java:458)
>        at org.apache.click.ClickServlet.handleRequest(ClickServlet.java:390)
>        at org.apache.click.ClickServlet.doPost(ClickServlet.java:294)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>        at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:533)
>        at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1351)
>        at 
> com.none.click.guice.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:98)
>        at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1322)
>        at 
> com.none.click.guice.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:98)
>        at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1322)
>        at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:473)
>        at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
>        at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:514)
>        at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>        at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:920)
>        at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:403)
>        at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:184)
>        at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:856)
>        at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
>        at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:247)
>        at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:151)
>        at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:114)
>        at org.eclipse.jetty.server.Server.handle(Server.java:352)
>        at 
> org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:596)
>        at 
> org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:1066)
>        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:805)
>        at 
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
>        at 
> org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:426)
>        at 
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:510)
>        at 
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.access$000(SelectChannelEndPoint.java:34)
>        at 
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)
>        at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:450)
>        at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.UnsupportedEncodingException: ISO-8859-1;
>        at 
> sun.nio.cs.StreamEncoder.forOutputStreamWriter(StreamEncoder.java:42)
>        at java.io.OutputStreamWriter.<init>(OutputStreamWriter.java:83)
>        at 
> org.eclipse.jetty.server.HttpWriter.getConverter(HttpWriter.java:268)
>        at org.eclipse.jetty.server.HttpWriter.write(HttpWriter.java:125)
>        at org.eclipse.jetty.server.HttpWriter.write(HttpWriter.java:107)
>        at 
> org.eclipse.jetty.io.UncheckedPrintWriter.write(UncheckedPrintWriter.java:271)
>        ... 36 more
> I was able to resolve the issue by overriding 
> AutoCompleteTextField#createBehavior
> and commenting the line:
> actionResult.setContentType(contentType);

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to