Re: [appengine-java] Problems with large request/response headers
Matt, There probably isn't anything you'll be able to do in the meantime. You may not see this when deployed since we are not using a different servlet engine in production. Can you go ahead and open an issue here for us to upgrade our SDK's version of Jetty? http://code.google.com/p/googleappengine/issues/list?can=2q=jetty It's something we'd eventually want to do anyway, and getting it into the issue tracker will mean it's on our radar. On Wed, Nov 18, 2009 at 8:32 AM, Matthew McGinty mcgin...@gmail.com wrote: Ikai, Reading all of the Jetty bug report you found, I see that it is possible to configure the size of the header buffer used by Jetty. This is done in the jetty.xml file. I don't see that file within my GAE project. I see appengine-web.xml. Does GAE expose/use jetty.xml or some equivalent? If so, where would I find it? If I can configure the Jetty that is bundled with GAE Dev server, then that would solve my problem. Thanks. Matt On Wed, Nov 18, 2009 at 11:23 AM, Matthew McGinty mcgin...@gmail.com wrote: Thanks Ikai for responding and for finding that Jetty bug report. It is marked as fixed in Jetty 6.1.11. Do you know if that fix is in the version of Jetty that is bundled with the GAE Dev server? I can't store that data in the session because the data being stored in the cookies is not being placed there by me. It is being placed there by the Application Server software I'm using which is running on top of the GAE. Specifically it is being placed there by OpenBD Google which is a version of BlueDragon (a CFML Engine) ported to run on GAE. BlueDragon is the Application Server that powers MySpace. http://www.openbluedragon.org/ http://wiki.openbluedragon.org/wiki/index.php/Category:GoogleAppEngine Storing such data in cookies is a requirement/feature of the CFML Engine. That is how Adobe's ColdFusion CFML Engine functions. It is jjust name/value pair data (String data)... variable defined to be in something called the client scope (in CFML speak). BD may be configured to store client scoped variables in either cookies or a database... so using the database option would work around this problem but it still seems like something that should be fixed for GAE. BlueDragon runs on top of various platforms: Microsoft .NET framework WebSphere Weblogic ServletExec and behind commercial grade webservers (IIS, and Apache) and does not exhibit this problem in any of those environments... only with Jetty. Matt On Mon, Nov 16, 2009 at 5:36 PM, Ikai L (Google) ika...@google.com wrote: Matt, This looks like it may be a JeTTy issue: http://jira.codehaus.org/browse/JETTY-336 That being said, I'm curious as to what data you are storing in the cookie. Less than 1.5% of sites pass cookies larger than 1501 bytes, and there are performance implications for passing large amounts of cookies: http://yuiblog.com/blog/2007/03/01/performance-research-part-3 Is this data you can store in the session instead? On Fri, Nov 13, 2009 at 12:05 PM, Matthew McGinty mcgin...@gmail.com wrote: I'm using the GAE Java Dev Server (i.e. Jetty). When I request a page that sends a large amount of cookie data to the browser and then re-request the page (so that the browser sends the cookies back to the server) I get this stacktrace: == Nov 13, 2009 6:35:13 PM com.google.apphosting.utils.jetty.JettyLogger warn WARNING: handle failed java.io.IOException: FULL head at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:276) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at org.mortbay.io.nio.SelectChannelEndPoint.run (SelectChannelEndPoint.java:396) at org.mortbay.thread.BoundedThreadPool$PoolThread.run (BoundedThreadPool.java:442) == The behavior I see is that the browser receives what seems to be a completely empty response body, and the access log does not show the request at all (likely because the request/response protocol was halted when the exception occured). If I configure my browser to send its requests through a diagnostic proxy tool, I can see that the request headers being sent are about 5k total. But the response takes 2-3 minutes to come. Once it does, the proxy tool shows me only response headers (no response body): === HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Expires: Thu, 01 Jan 1970 00:00:00 GMT Set-Cookie: cookie name 1=cookie value 1 Set-Cookie: cookie name 2=cookie value 2 Set-Cookie: cookie name 3=cookie value 3 Transfer-Encoding: chunked Server: Jetty(6.1.x) === which I suppose explains why the browser renders it as an empty response. I found a clue here:
Re: [appengine-java] Problems with large request/response headers
Matt, This looks like it may be a JeTTy issue: http://jira.codehaus.org/browse/JETTY-336 That being said, I'm curious as to what data you are storing in the cookie. Less than 1.5% of sites pass cookies larger than 1501 bytes, and there are performance implications for passing large amounts of cookies: http://yuiblog.com/blog/2007/03/01/performance-research-part-3 Is this data you can store in the session instead? On Fri, Nov 13, 2009 at 12:05 PM, Matthew McGinty mcgin...@gmail.comwrote: I'm using the GAE Java Dev Server (i.e. Jetty). When I request a page that sends a large amount of cookie data to the browser and then re-request the page (so that the browser sends the cookies back to the server) I get this stacktrace: == Nov 13, 2009 6:35:13 PM com.google.apphosting.utils.jetty.JettyLogger warn WARNING: handle failed java.io.IOException: FULL head at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:276) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at org.mortbay.io.nio.SelectChannelEndPoint.run (SelectChannelEndPoint.java:396) at org.mortbay.thread.BoundedThreadPool$PoolThread.run (BoundedThreadPool.java:442) == The behavior I see is that the browser receives what seems to be a completely empty response body, and the access log does not show the request at all (likely because the request/response protocol was halted when the exception occured). If I configure my browser to send its requests through a diagnostic proxy tool, I can see that the request headers being sent are about 5k total. But the response takes 2-3 minutes to come. Once it does, the proxy tool shows me only response headers (no response body): === HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Expires: Thu, 01 Jan 1970 00:00:00 GMT Set-Cookie: cookie name 1=cookie value 1 Set-Cookie: cookie name 2=cookie value 2 Set-Cookie: cookie name 3=cookie value 3 Transfer-Encoding: chunked Server: Jetty(6.1.x) === which I suppose explains why the browser renders it as an empty response. I found a clue here: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200711.mbox/%3c8189103.1194033655205.javamail.j...@brutus%3e I've confirmed that if I delete the cookies from my browser and re- request... the problem does not occur for that request. In other words the problem only occurs when the browser is sending a large amount of request headers (In my case cookies it already received from a previous request to the test page). However the solution given is to switch from Jetty to Tomcat, which is not something that can be done when using GAE Java Dev server. So... does anyone know if the Jetty that's bundled with GAE Java Dev Server can be configured to use a larger buffer for the *request* headers? And if so... how? A JVM System property perhaps... passed in the WEB-INF/appengine- web.xml file? I also ran the same test/request on regular (non-Google App Engine) Jetty (v 6.1.16) and get the same observed behavior (empty response received) however the stacktrace is quite different suggesting that the problem is now with the size of the buffer used for the *response* headers: = java.lang.ArrayIndexOutOfBoundsException: 4096 at org.mortbay.io.ByteArrayBuffer.poke(ByteArrayBuffer.java: 268) at org.mortbay.io.AbstractBuffer.put(AbstractBuffer.java:456) at org.mortbay.jetty.HttpFields$Field.put(HttpFields.java: 1384) at org.mortbay.jetty.HttpGenerator.completeHeader (HttpGenerator.java:523 ) at org.mortbay.jetty.HttpConnection.commitResponse (HttpConnection.java:6 11) at org.mortbay.jetty.HttpConnection$Output.flush (HttpConnection.java:946 ) at org.mortbay.jetty.AbstractGenerator$OutputWriter.flush (AbstractGenera tor.java:733) at java.io.PrintWriter.flush(Unknown Source) = I once again configured my browser to send all its requests through my diagnostic proxy tool. The tool shows me that the response that comes from Jetty (after 2-3 minutes) is: HTTP/1.1 413 FULL head Connection: close Server: Jetty(6.1.16) The 413 Response status code means Request Entity Too Large and the HTTP spec says that the server may close the connection in that case. Once again I used my proxy tool to confirm that the size of the request headers is about 5k. In all cases it is a simple GET request so there is no request body (i.e. payload). Can't Jetty take more than 5k of request headers??? -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to
