[ grinder-Bugs-3206627 ] Line endings under Apache

Bugs item #3206627, was opened at 2011-03-11 18:51
Message generated for change (Tracker Item Submitted) made by stevenswart
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=118598&aid=3206627&group_id=18598

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: HTTP Plugin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Steven Swart (stevenswart)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line endings under Apache

Initial Comment:
I recently ran into a problem while running a Grinder script against Apache. The same script was succeeding against IIS, but against Apache was  throwing the following exception:

2011/03/11 4:22:31 PM (thread 0 run 0 test 501): Aborted run due to
Java exception calling TestRunner
Java exception calling TestRunner
      File "C:\Testing\grinder\newuicreateprojectcreatetemplate1.py", line
152, in page5
      File "C:\Testing\grinder\newuicreateprojectcreatetemplate1.py", line
281, in __call__
Caused by: java.io.EOFException: Premature EOF encountered
      at HTTPClient.StreamDemultiplexor.read(StreamDemultiplexor.java:300)
      at HTTPClient.RespInputStream.read(RespInputStream.java:155)
      at HTTPClient.HTTPResponse.readResponseData(HTTPResponse.java:1011)
      at HTTPClient.HTTPResponse.getData(HTTPResponse.java:515)

I got hold of the source, and discovered that line 300 of StreamDemultiplexor.java was throwing the exception.

                      if (rcvd == -1)
                          throw new EOFException("Premature EOF encountered");

I commented out this code, rebuilt the Grinder jar, and my script then executed successfully against Apache
with no failures.

The only difference I could find in the output returned by Apache vs. IIS is that IIS uses two bytes, <CR><LF> to denote the end of a line, while Apache only uses one byte, <LF>. It seems to me that The Grinder is not taking account of this difference.

Examining the code, I suspect the fault lies in lines 1010-1011 of HTTPResponse.java:

      final int maximumBytes =
        Math.min(Data.length - off, bandwidthLimiter.maximumBytes(off));

Or in the calculations preceding it.

I am now happy, I have a work-around, but I'm sure the community would appreciate a proper fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=118598&aid=3206627&group_id=18598

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d