I've made a change that prevents JMeter from encoding the values sent by the browser. It's not a perfect solution yet - if you change things in the GUI (after recording is done), it can mess things up. Thus, my next step will be to add checkboxes to the HTTP Request gui to indicate whether each argument should be encoded or not. The problem is, some values need to be encoded, and some should not be, but detecting the difference will require some work.
To the parameter panel, I am thinking of adding a third and fourth column. The third column will hold the value to actually be sent to the server (ie the encoded value). The fourth column will hold a checkbox indicating whether URL encoding should be performed. Thus, you type in the second column, and the encoded (or not encoded, depending) value appears in the third column as you type. You'll also be able to edit the third column directly, to maximize your opportunities to screw things up. Um, I might just make a whole different GUI for all this - call it the "Advanced" HTTP Request, or something... Any suggestions would be greatly appreciated :-) -Mike On 13 Aug 2002 at 0:07, Eric Siegerman wrote: > Ok, so this business of the HTTP proxy URL-encoding stuff is > biting me now. > > Why does this happen? It seems to me that the proxy should pass > along exactly what it got, unless there's a good reason to do > otherwise. That invites the question: is there a good reason > for URL-encoding the data? What purpose is served by modifying > it, in however supposedly-benign a way? > > On Fri, Aug 09, 2002 at 10:25:30AM -0400, Mike Stover wrote (over on jmeter-dev): > > It seems that what is needed is a new type of proxy server that generates SOAP > > Samplers, instead of normal HTTP Samplers. Not that your communications are > > using SOAP necessarily, but the form is the same (XML through HTTP). > > I wasn't following the quoted thread closely, but this suggestion > seems to be a response to someone else's URL-encoding problems. > If so, it wouldn't help me. My problem is not with XML-formatted > data, but with bog-standard HTML forms. My browser encodes a > particular form as "multipart/form-data", but JMeter URL-encodes > the whole request body (all of its MIME parts crunched into one > huge long line) and zaps the encoding to > "application/x-www-form-urlencoded". Not surprisingly, the app > server hasn't a clue what to do with this. > > Of course, a special case could be added for > "multipart/form-data" forms too (perhaps not as visibly as a > separate subclass). But better than multiplying kludges, it > seems to me, would be to just make the existing proxy > transparent. > > Here are the ways in which the proxy incorrectly modifies the > data (perhaps only a partial list; this is based only on the form > submission that's causing me grief): > - form body munging as described above > - the response headers are changed to be terminated by LF; > they're supposed to be CRLF's, and are before the proxy gets > hold of them [1] > > There are other modifications, but they're all correct -- either > necessary, or else unnecessary but innocuous (e.g. reordering > headers). If a list of these would be useful, I can post one. > > I'm willing to take a quick stab at this (but haven't time for > more, so I can't promise anything). But before I do, I'd like to > know that I'm not going off on the wrong track. So, is there a > good reason for the current behaviour, or is it a bug / > implementation artifact? > > Thanks much. > > > [1] "[...] a bare CR or LF MUST NOT be substituted for CRLF > within any of the HTTP control structures (such as header > fields and multipart boundaries)." > - RFC 2068, p. 25, emphasis in original > > > P.S. Sorry if this sounds a bit snarky. Normally I'd hold onto > it overnight and revise it in the morning. But deadline pressure > kind of prevents that :-( > > -- > > | | /\ > |-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED] > | | / > Anyone who swims with the current will reach the big music steamship; > whoever swims against the current will perhaps reach the source. > - Paul Schneider-Esleben > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
