Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANbaA-qDCGebUb-mFwXNL4R2vN-B+xjQ5XPJw95sGUFrT3c2nw@mail.gmail.com>
References: 
 <CANbaA-pLs7vA9Qf+Tx29MiyVuWBttSUwz4fhsEedsraXROFpCw@mail.gmail.com>
	<CAOGo0VbBn2XSHAjQxe_1Gyq1uWAzFNxRYHvAxKcG1Cs62pubGg@mail.gmail.com>
	<CANbaA-qDCGebUb-mFwXNL4R2vN-B+xjQ5XPJw95sGUFrT3c2nw@mail.gmail.com>
Date: Mon, 3 Sep 2012 16:36:29 +0100
Message-ID: 
 <CAOGo0Va+MJSiVs=Ovn2=vGHXtFxjttmvXE0Ms=QAQLTr4u7MyA@mail.gmail.com>
Subject: Re: HTTP with custom methods
From: sebb <sebbaz@gmail.com>
To: dev@jmeter.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On 3 September 2012 16:21, Christopher Brind <chris@brindysoft.com> wrote:
> Hi,
>
> Thanks for the reply.
>
> On Mon, Sep 3, 2012 at 4:13 PM, sebb <sebbaz@gmail.com> wrote:
>>
>> On 3 September 2012 14:51, Christopher Brind <chris@brindysoft.com> wrote:
>> > Hi,
>> >
>> > My current customer has a requirement to use JMeter for testing their web
>> > application which uses custom HTTP methods beyond the list presented in the
>> > HTTP sampler GUI.  To support this I have ended up forking JMeter and
>> > implementing this in house.  I have been asked to see if the JMeter
>> > community will accept the changes back in to the main source tree so that
>> > my customer doesn't need to maintain the fork.
>> >
>> > The changes are:
>> >
>> > - If the HC4 implementation is selected set the JLabelledChoice for
>> > "method" to editable
>> > - Changed the ordering of reading and writing of the test element
>> > properties (because being able to set the method text on the choice depends
>> > on it being editable)
>> > - Changed HTTPHC4Impl to create a new anonymous instance of HttpRequestBase
>> > which simply passes through the entered method and URI
>>
>> I assume these new methods don't support body content?
>
> That's correct.  It wasn't a requirement for my customer, but I can
> see how that might be useful.  Let me check with the customer to see
> how they feel about me adding support for that (in my own time if
> necessary).

OK.

No need to do so (unless you want) as I expect the change will be
useful as is - if only to see what happens if clients send unusual
requests!

The easiest way to support body content is to treat the method much
the same way as PUT or PATCH.
[POST handling is more complicated because of form-data-encoding]

The simplest would be to send content iff it is provided, otherwise
send URL parameters if any.
This would not need any further changes to the GUI, which is already
rather crowded.

>
>>
>> > There did not appear to be any unit tests to update for this and the
>> > existing unit tests still pass.
>> >
>> > Please let me know if this is desirable and I will send through the diff.
>>
>> Seems reasonable, but we would need to see the exact changes.
>>
>> The best way to provide patches and and enhancement code is via the
>> issue tracker; JMeter uses Bugzilla for this.
>> So please create an account, and attach the patches (diff -u format
>> please). For new files, these can be plain source rather than diff
>> format.
>
> Will do.
>
> Cheers,
> Chris
>
>>
>> > Thanks in advance.
>> >
>> > Regards,
>> > Chris