If there is agreement that this is a bug, and the fix can be rolled into a
snapshot, I can test further to find out where the next gotcha is with large
valued contentLengths.







From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman
Sent: Monday, October 17, 2011 5:09 PM
To: General Discussion for the Resin application server
Subject: [Resin-interest] Possible Bug Fix?


In AbstractHttpRequest I am seeing that the global variable _contentLength
it appropriately a "long".  Love that.  Been a thorn in our side for a long


However in looking at this method (also inside of AbstractHttpRequest):


  protected void setContentLength(CharSegment value)


    int contentLength = 0;

    int ch;

    int i = 0;


    int length = value.length();

    for (;

         i < length && (ch = value.charAt(i)) >= '0' && ch <= '9';

         i++) {

      contentLength = 10 * contentLength + ch - '0';



    if (i > 0)

      _contentLength = contentLength;



The method is internally using an int, so the values get truncated or
"wrapped" to negative values.  Internally I believe that method should use a
long for the local contentLength variable.


This should help prevent HttpRequest from incorrectly throwing this for
request larger than 2GB (which is what the user community would see in their
logs if they are dumping exceptions):

      throw new com.caucho.server.dispatch.BadRequestException("POST
requires content-length");





resin-interest mailing list

Reply via email to