Re: [Resin-interest] Content-Length
Aaron Freeman wrote: I see from your link that Sun uses an int, but couldn't that be arbitrary? I can't speak to whether the expert committee's decision was arbitrary or not. :) But once they've made a decision, it is a rule that must be implemented. I don't believe Jakarta, and other implementations have this limit -- I just looked and they are using a long. This is a seriously limiting factor and may require us to swap out our underlying servers from Resin (which I really, really don't want to do). Where are you seeing this? Jakarta used to have Tomcat, which I assume is what you're referring to, but every reference I can find in Tomcat 6.x (BaseRequest, Request, RequestFascade, ApplicationHttpRequest, DummyRequest) returns int for getContentLength(). If someone has figured a way around the spec limitation, that's great news! Maybe newer versions of Java had changed this, but I didn't think you could alter method signatures. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Content-Length
On Aug 13, 2007, at 6:16 AM, Aaron Freeman wrote: I see from your link that Sun uses an int, but couldn't that be arbitrary? I don't believe Jakarta, and other implementations have this limit -- I just looked and they are using a long. This is a seriously limiting factor and may require us to swap out our underlying servers from Resin (which I really, really don't want to do). The HttpServletRequest.getContentLength() will still return int, but Resin will be able to use a long value internally (in 3.1.3). However, you could also use chunked-encoding for your uploads (assuming you have control over your client). That would avoid the 32- bit issue entirely. -- Scott Thanks, Aaron Freeman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Knystautas Sent: Friday, August 10, 2007 10:16 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Content-Length Aaron Freeman wrote: Looking at com.caucho.server.connection.AbstractHttpRequest and com.caucho.server.http.HttpRequest I see that contentLength is being defined as an int, which limits file uploads to a size of 2,147,483,647. How painful would it be to convert this limit to a long so that we can have substantially larger files? That's a servlet API limitation, not something resin can do without breaking their support for the spec really: http://java.sun.com/products/servlet/2.5/docs/servlet-2_5-mr2/ index.html -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Content-Length
On Aug 13, 2007, at 11:20 AM, Aaron Freeman wrote: I see from your link that Sun uses an int, but couldn't that be arbitrary? I don't believe Jakarta, and other implementations have this limit -- I just looked and they are using a long. This is a seriously limiting factor and may require us to swap out our underlying servers from Resin (which I really, really don't want to do). The HttpServletRequest.getContentLength() will still return int, but Resin will be able to use a long value internally (in 3.1.3). Ok so this problem will just go away with version 3.1.3 or it will require some special calls somewhere? It depends. If the application code is using HttpServletRequest.getContentLength(), then you will still have a problem. If it's just using getInputStream(), then it will just go away. -- Scott However, you could also use chunked-encoding for your uploads (assuming you have control over your client). That would avoid the 32- bit issue entirely. Let me check with the developer of the client and see what this entails. Thanks, Aaron Freeman ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
