https://issues.apache.org/bugzilla/show_bug.cgi?id=49039
Philippe Mouawad <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO --- Comment #5 from Philippe Mouawad <[email protected]> 2012-02-06 06:52:49 UTC --- (In reply to comment #2) > I can confirm this. > > when recording HTTP data with JMeter, I'd assume that the request is sent to > the server just like the browser would send it. > This is not the case in two examples I've run across. > > As you'll know, when recording with HTTP Proxy Server, JMeter will be creating > HTTP Samplers and then use their sample method to realize the request, > returning the return value to the browser. > So we need to create a HTTP Sampler which produces the same request as the > browser would have done. > > When looking at HttpRequestHdr.populateSampler, I see that > ConversionUtils.getEncodingFromContentType > is called. In case the encoding is not supported (returns null) we look in the > pageEncodings and formEncodings maps (when and how are they populated??) and > if > we find nothing here, we use: > postData = new String(rawPostData); > meaning we convert the bytes to a string based on the platform-specific > default > encoding. > > In my examples this breaks the communication, so not only replay but record > does not work. > In one case I have no Content-Type header in the request, and new > String(rawPostData) seems to break it, in the other case, I have a > Content-Type: application/soap+msbin1 header, where > "getEncodingFromContentType" returns null. > > We really should make sure JMeter sends exactly what it received to the server > when acting as proxy, and even better would be if this would work when > executing the test. > > For the former, the solution I found seems to be to change the line > HttpRequestHdr: postData = new String(rawPostData); > to: > postData = new String(rawPostData, PostWriter.ENCODING); > to match the encoding which is used when executing the request in case no > encoding is set. > This seems reasonable, as indeed Postwriter uses ENCODING const when encoding is null. > I also have a problem with the line > if (firstLine && !CharUtils.isAscii((char) x)){ > which I can solve by commenting this out... Regarding this, would it be possible to attach to Bugzilla à fiddler capture of the failing request. CAN you give more information about the tested app, is it a binary soap webservice ? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
