jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: HTTPClient4 missing filename for file uploads
Date Tue, 26 May 2015 18:29:15 GMT
No objection for me.
Although having 3rd party plugins use different versions of dependencies
used by core exposes to issues and as such should be avoided.

In this particular case , if we upgrade we should anyway update the code to
use the updated method.

Did you raise a bug on HttpClient project ?

Thanks


On Tuesday, May 26, 2015, Andrey Pokhilko <apc4@ya.ru> wrote:

> Sebastian,
>
> I want to re-raise this topic again.
>
> The change is small and harmless, does not increase complexity, does not
> break any compatibilities. But it fixes compatibility with newer HT
> versions.
>
> Why you don't want to help people with custom plugins or libraries if it
> has no disadvantages?
> If your "I think..." is soft enough, may I commit this change, please?
>
> Andrey Pokhilko
>
> On 05/15/2015 03:06 PM, sebb wrote:
> > On 15 May 2015 at 12:41, Andrey Pokhilko <apc4@ya.ru <javascript:;>>
> wrote:
> >> It is not a bug in HC, they just deprecated that method since 4.3 and
> >> broke old behavior for deprecated method.
> > That's unfortunate, especially if it was not essential.
> >
> >> Even if we'll ask them to fix
> >> it and restore old behavior, they might say that we're using old version
> >> so to get the fix we'll need to upgrade our lib (which was already
> >> discussed and not likely to happen soon).
> > It might still be worth raising on the HC mailing list, as there are
> > likely other apps that are affected.
> > At the very least, the release notes ought to mention this behavioural
> change.
> >
> > I think it is out of scope for JMeter to fix its code to support
> > non-standard versions of jars.
> >
> > This thread has documented at least two work-rounds that end-users can
> apply.
> >
> >> Andrey Pokhilko
> >>
> >> On 05/15/2015 02:25 PM, sebb wrote:
> >>> On 15 May 2015 at 12:24, sebb <sebbaz@gmail.com <javascript:;>>
wrote:
> >>>> Seems to me that this is not a bug in JMeter.
> >>>>
> >>>> It may perhaps be a bug in a later version of HttpComponents, but
> >>>> JMeter is not currently using that version.
> >>>> Before adding code to JMeter, I think we need to determine whether it
> >>>> is a bug in HC.
> >>>>
> >>>> I don't think we need to fix JMeter to support customised
> installations.
> >>>> Since JMeter is open source, the user can apply the fix for
> themselves.
> >>> Or indeed apply the fix to the HC mime code.
> >>>
> >>>> Once we have determined whether of not this is a bug in HC, we can
> >>>> determine whether or not JMeter needs to be updated when it is
> >>>> upgraded to the latest version of HC.
> >>>>
> >>>>
> >>>>
> >>>> On 15 May 2015 at 11:04, Andrey Pokhilko <apc4@ya.ru <javascript:;>>
> wrote:
> >>>>> Right.
> >>>>>
> >>>>> Andrey Pokhilko
> >>>>>
> >>>>> On 05/15/2015 12:55 PM, UBIK LOAD PACK Support wrote:
> >>>>>> AFAIU, setting name would not break existing behaviour and fix
the
> >>>>>> situation right ?
> >>>>>>
> >>>>>>
> >>>>>> On Fri, May 15, 2015 at 11:50 AM, Andrey Pokhilko <apc4@ya.ru
> <javascript:;>> wrote:
> >>>>>>
> >>>>>>> I investigated it more. It happened that with stock httpmime-4.2.6
> it
> >>>>>>> works, but user has upgraded HTTPComponents libraries to
support
> custom
> >>>>>>> plugins. Since version 4.3 of httpmime they deprecated that
> constructor
> >>>>>>> and don't have automatic logic to set filename from file
if
> filename is
> >>>>>>> null.
> >>>>>>>
> >>>>>>> This seems to be a deadlock situation for user unless we're
making
> a
> >>>>>>> step towards custom plugin users and will call different
> super-constructor.
> >>>>>>>
> >>>>>>> Sebb, what's your opinion?
> >>>>>>>
> >>>>>>> Andrey Pokhilko
> >>>>>>>
> >>>>>>> On 05/15/2015 12:05 AM, sebb wrote:
> >>>>>>>> OK, it does look like a bug, but according to the source
for http
> mime
> >>>>>>>> 4.2.6 if filename is null it uses file.getName() anyway,
so AFAICT
> >>>>>>>> your proposed fix would have no effect.
> >>>>>>>>
> >>>>>>>> This needs further investigation.
> >>>>>>>>
> >>>>>>>> On 14 May 2015 at 19:00, Andrey Pokhilko <apc4@ya.ru
> <javascript:;>> wrote:
> >>>>>>>>> Java implementation does well, providing required
parameter:
> >>>>>>>>>
> >>>>>>>>>     POST http://localhost/api/file/upload/
> >>>>>>>>>
> >>>>>>>>>     POST data:
> >>>>>>>>>     -----------------------------7d159c1302d0y0
> >>>>>>>>>     Content-Disposition: form-data; name="jtl_file";
> >>>>>>>>>     *filename="011f07efb04762311137.jtl.gz" *
> >>>>>>>>>     Content-Type: application/octet-stream
> >>>>>>>>>     Content-Transfer-Encoding: binary
> >>>>>>>>>
> >>>>>>>>>     <actual file content, not shown here>
> >>>>>>>>>     -----------------------------7d159c1302d0y0--
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Andrey Pokhilko
> >>>>>>>>>
> >>>>>>>>> On 05/14/2015 07:57 PM, sebb wrote:
> >>>>>>>>>> On 14 May 2015 at 17:36, Andrey Pokhilko <apc4@ya.ru
> <javascript:;>> wrote:
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>> I'm trying to resolve a user issue when
he claims that file
> upload
> >>>>>>>>>>> scenario is missing "filename" parameter.
When I use
> HTTPClient4 I get
> >>>>>>>>>>> failing file upload request:
> >>>>>>>>>>>
> >>>>>>>>>>>     POST http://localhost/api/file/upload/
> >>>>>>>>>>>
> >>>>>>>>>>>     POST data:
> >>>>>>>>>>>     --cJfjtjR2_380MwSzTd_SQdQfG51aS5D
> >>>>>>>>>>>     Content-Disposition: form-data; name="jtl_file";
> >>>>>>>>>>>     Content-Type: application/octet-stream
> >>>>>>>>>>>
> >>>>>>>>>>>     <actual file content, not shown here>
> >>>>>>>>>>>     --cJfjtjR2_380MwSzTd_SQdQfG51aS5D--
> >>>>>>>>>>>
> >>>>>>>>>>> While for HTTPClient3.1 I have successful
request with:
> >>>>>>>>>>>
> >>>>>>>>>>> POST http://localhost/api/file/upload/
> >>>>>>>>>>>
> >>>>>>>>>>> POST data:
> >>>>>>>>>>> --wqkPl1L84AqGtph2Cgr79xYPJVMxntF4IJ
> >>>>>>>>>>> Content-Disposition: form-data; name="jtl_file";
> >>>>>>>>>>> *filename="011f023437.jtl.gz" *
> >>>>>>>>>>> Content-Type: application/octet-stream
> >>>>>>>>>>> Content-Transfer-Encoding: binary
> >>>>>>>>>>>
> >>>>>>>>>>> <actual file content, not shown here>
> >>>>>>>>>>> --wqkPl1L84AqGtph2Cgr79xYPJVMxntF4IJ--
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> After digging into HTTPClient4 implementation
I found that
> we're
> >>>>>>> really
> >>>>>>>>>>> do not pass filename parameter to underlying
http library.
> This is
> >>>>>>> easy
> >>>>>>>>>>> to fix by changing this line:
> >>>>>>>>>>>
> >>>>>>>
> https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L966
> >>>>>>>>>>> from
> >>>>>>>>>>>
> >>>>>>>>>>> super(file, mimeType);
> >>>>>>>>>>>
> >>>>>>>>>>> into:
> >>>>>>>>>>>
> >>>>>>>>>>> super(file, file.getName(), mimeType, null);
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Questions:
> >>>>>>>>>>>
> >>>>>>>>>>>  1. Is that a bug? Maybe a known one? Or
this is intended
> behavior.
> >>>>>>>>>> It would be useful to know what the Java implementation
does.
> >>>>>>>>>>
> >>>>>>>>>>>  2. Should I fix this as demonstrated (if
this is a bug)?
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Andrey Pokhilko
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
>
>

-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message