You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2014/02/15 11:57:52 UTC

[Bug 56141] New: while recording on a page through a proxy server our application is not behaving other way

https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

            Bug ID: 56141
           Summary: while recording on a page through a proxy server our
                    application is not behaving other way
           Product: JMeter
           Version: 2.9
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: major
          Priority: P2
         Component: Main
          Assignee: issues@jmeter.apache.org
          Reporter: dmajhi@gmail.com

1. go to http://projects.csmpl.com/nbpdcl/
user id: santa
password : password1

2. Go to Registration under Grievance Monitoring

3 i)   Consumer number 123456
  ii)  Name : Any name
  iii) Phone # : any cell number (should not DND activated)
  iv)  Gender : Fill as you want
  v)   District : Araia 
  vi)  Block : Araia
  vii) Panchayat : Araia Basti
  viii)Address1 : anything
  ix)  Complaint Category : Meter Installation
  x)   Complaint Sub-Category : New Meter
  x1 Complaint Details  : Some Text

4. Click on Submit button

With the above data & 

NO PROBELM : without proxy server we are able to register the complain
DEFECT :     But With proxy server & starting it through JMETER we are not able
to do any thing even clicking on Submit(step 4) button application is clearing
all the data entered

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

--- Comment #15 from Sebb <se...@apache.org> ---
This does look suspicious.
I wonder why the extra CRLF is present?

Maybe there is some code that puts CRLF after lines in the output - if a line
is empty for some reason the result would be two consecutive CRLF pairs.

It would be helpful to see the full headers for both scenarios

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

--- Comment #13 from Dan <ja...@yahoo.com> ---
>From the MultipartEntityBuilder, the setLaxMode() changes something to allow it
to work


    public MultipartEntityBuilder setLaxMode() {
        this.mode = HttpMultipartMode.BROWSER_COMPATIBLE;
        return this;
    }
    public MultipartEntityBuilder setStrictMode() {
        this.mode = HttpMultipartMode.STRICT;
        return this;
    }

I haven't delved deeper than this, only that it stopped the problem from
happening when observing in wire shark, which was enough to get me rolling on
what I was trying to accomplish

But you could very well be right. "The multipart dissector could not find the
required boundary parameter." is the error description of wireshark's internal
parser. 

If you know the underlying answer, I'd be interested!

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

--- Comment #6 from Dan <ja...@yahoo.com> ---
I'm sorry, no I didn't run regression tests. I was going to submit a patch,
however; the changes would require the use of newer jars. I would need to
modify the ant properties to use the 4.3.5 version of the http client mime jar.
If I did that, I would also want to use the same version for the other 2 http
client jars. 

If such jars were to be used, and it were my project, I would also want to
upgrade the code to leverage these jars, by changing the deprecated method
calls and other improvements. 

So in order to provide a patch, I could take many different routes. I'm not
honestly sure of the best approach. 

I just provided you with the solution for this one case scenario. I was really
hoping that you could use the snippet I provided with the 4.3.5 jars, and sort
of take it from there.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

--- Comment #12 from Dan <ja...@yahoo.com> ---
Created attachment 32255
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=32255&action=edit
Difference in wireshark

>From wireshark, the top half is the request that fails - the bottom half works
when you setLaxMode()

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

--- Comment #8 from Dan <ja...@yahoo.com> ---
Created attachment 32251
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=32251&action=edit
the fix

Ok, so I merged the fix I made from 2.11 into the trunk's code, and came up
with this patch for you to look at. 

The important parts are 

Use MultipartEntityBuilder instead of the new MultipartEntity

and

 mep.setLaxMode();

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

--- Comment #11 from Sebb <se...@apache.org> ---
(In reply to Dan from comment #10)

> And yes, I can test it again. I can easily reproduce it locally, and make
> sure this bug is still fixed. It might be a little bit before I can, but I
> will.

Thanks.

> It seems as though it happens with an Oracle ADF webapp but only for certain
> pages. It's definitely the boundary string though

The boundary string value _should_ be irrelevant, however maybe the charset
attribute is causing an issue (see comment 3 above)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

--- Comment #1 from Sebb <se...@apache.org> ---
I can reproduce the problem.

There are some minor differences between what JMeter sends and what the browser
sends, but so far I have not been able to determine exactly which differences
are significant.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

Dan <ja...@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |java.junkee@yahoo.com

--- Comment #4 from Dan <ja...@yahoo.com> ---
I actually have a fix for this, but I'm not sure exactly how to go about
checking in the code -
The problem is that it requires newer httpmime jar, and possibly the httpclient
and http code ones. I'm using 4.3.5 in my fix. 

I modified the HTTPHC4Impl class, and therefore if I were to either check it in
or create a new one, it would require a dependency change and I don't know if
that is acceptable. A lot of code is deprecated. 

The way that I was able to solve the problem was that inside of the method
org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sendPostData(HttpPost),
inside of the  // Check if we should do a multipart/form-data or an
        // application/x-www-form-urlencoded post request
        if(getUseMultipartForPost()) {
I changed the code to the newer MultipartEntityBuilder and most importantly,
had to call the setLaxMode(). 

if(getUseMultipartForPost()) {
            // If a content encoding is specified, we use that as the
            // encoding of any parameter values
            Charset charset = null;
            if(haveContentEncoding) {
                charset = Charset.forName(contentEncoding);
            }

            // Write the request to our own stream
            MultipartEntityBuilder mep = MultipartEntityBuilder.create();

            // Create the parts
            // Add any parameters
            PropertyIterator args = getArguments().iterator();
            while (args.hasNext()) {
               HTTPArgument arg = (HTTPArgument) args.next().getObjectValue();
               String parameterName = arg.getName();
               if (arg.isSkippable(parameterName)){
                   continue;
               }

               FormBodyPart formPart;
               mep.addBinaryBody(arg.getName(),
arg.getValue().getBytes("ASCII"));
               mep.setLaxMode();
            }

            // Add any files
            // Cannot retrieve parts once added to the MultiPartEntity, so have
to save them here.
            FileBody[] fileBodies = new FileBody[files.length];
            for (int i=0; i < files.length; i++) {
                HTTPFileArg file = files[i];
                fileBodies[i] = new FileBody(new File(file.getPath()));

                mep.addPart(file.getParamName(), fileBodies[i] );
            }

            HttpEntity pst = mep.build();
            post.setEntity(pst);

            if (pst.isRepeatable()){
                ByteArrayOutputStream bos = new ByteArrayOutputStream();
                for(FileBody fileBody : fileBodies){
                   // fileBody.hideFileData = true;
                }
                pst.writeTo(bos);

                bos.flush();
                // We get the posted bytes using the encoding used to create it
                postedBody.append(new String(bos.toByteArray(),
                        contentEncoding == null ? "US-ASCII" // $NON-NLS-1$
this is the default used by HttpClient
                        : contentEncoding));
                bos.close();
            } else {
                postedBody.append("<Multipart was not repeatable, cannot view
what was sent>"); // $NON-NLS-1$
            }


        } else { // not multipart

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

Philippe Mouawad <p....@ubik-ingenierie.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #5 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Hello Dan,
Thanks for investigation.

Could you submit a patch on this ? it will be easier to understand.
Also did you run ant test to check no regression is introduced by this change ?
Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

--- Comment #14 from Dan <ja...@yahoo.com> ---
After looking at the differences between setLaxMode and STRICT, I see that the
former uses the HttpBrowserCompatibleMultipart class to build the entity, and I
wonder if the problem exists when it inserts

Content-Transfer-Encoding: 8bit\r\n\r\n 

The 3 bytes it says it has in the problem sample, include 0x0d0a so it is
including the cr and nl in the data.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

--- Comment #10 from Dan <ja...@yahoo.com> ---
Yes, I see what you're saying. 
Both points are valid and it shouldn't matter if you want to change those. I
left that in by accident

And yes, I can test it again. I can easily reproduce it locally, and make sure
this bug is still fixed. It might be a little bit before I can, but I will.

It seems as though it happens with an Oracle ADF webapp but only for certain
pages. It's definitely the boundary string though

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

Sebb <se...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|while recording on a page   |Application does not behave
                   |through a proxy server our  |correctly when using HTTP
                   |application is not behaving |Recorder
                   |other way                   |

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

--- Comment #3 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
I note one difference:
KO:
Content-Type: multipart/form-data; boundary=94tKRetqHIuE-vOYibNRsao99Mo4g9;
charset=UTF-8

OK:
Content-Type: multipart/form-data;
boundary=---------------------------7d159c1302d0y0

Although recorded sampler is identical.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

Philippe Mouawad <p....@ubik-ingenierie.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |p.mouawad@ubik-ingenierie.c
                   |                            |om

--- Comment #2 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Note that it works with Java Implementation, the issue is within the Submit
request, as if I record all with HTTP4 and last with Java is works

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

--- Comment #9 from Sebb <se...@apache.org> ---
Thanks, that makes it easier to review.

I think there are some problems with the patch:

987: the charset may not be ASCII, should use "charset" instead.

993: ViewableFileBody is required in order to support the Tree View Listener

and the trivial:
1042: spurious change to spacing (not relevant to the bug)

These are fixable, and I assume the patch would still work if these changes
were made, but that is not easy for us to test.

Would you be able to fix test the above changes?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

--- Comment #16 from Dan <ja...@yahoo.com> ---
Whenever you want to, can you attach a patch that you would like for me test
against the trunk or another version? 

I can give it a whirl.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 56141] Application does not behave correctly when using HTTP Recorder

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56141

--- Comment #7 from Sebb <se...@apache.org> ---
Would you be able to provide a patch for just the code that you changed?

It's very difficult to work out exactly what you have changed in the method
HTTPHC4Impl.sendPostData(HttpPost) from the Bugzilla comment.

Other aspects of the change (updating jar versions) are relatively easy to do.

-- 
You are receiving this mail because:
You are the assignee for the bug.