click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Schellink (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLK-757) duplicate Content-Type Response header on AJAX requests
Date Sun, 27 Mar 2011 17:01:05 GMT

    [ 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

Mime
View raw message