DO NOT REPLY [Bug 49039] Proxy : Bug with multipart bytes

[bu...@apache.org]

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

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

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

--- Comment #5 from Philippe Mouawad <p....@ubik-ingenierie.com> 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.