You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Andrey Pokhilko <ap...@ya.ru> on 2015/05/14 18:36:09 UTC
HTTPClient4 missing filename for file uploads
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.
2. Should I fix this as demonstrated (if this is a bug)?
--
Andrey Pokhilko
Re: HTTPClient4 missing filename for file uploads
Posted by Andrey Pokhilko <ap...@ya.ru>.
Very predictable.
Andrey Pokhilko
On 05/15/2015 02:24 PM, sebb 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.
>
> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
Re: HTTPClient4 missing filename for file uploads
Posted by Andrey Pokhilko <ap...@ya.ru>.
I contacted HTTP Components team and regression was fixed in branch 4.5.x
Andrey Pokhilko
On 05/27/2015 06:13 AM, Philippe Mouawad wrote:
> I think for faster fix:
> - it should be fixed in jmeter as anyway we use a deprecrated method
> (probably removed in future version of httpmime). We can see it as a
> workaround but this approach has been taken in the past for httpclient bugs.
>
> - report a bug to httpmime
>
> Otherwise we slow down the fix for our project , seen from customer
> perspective of jmeter , the issue is in jmeter.
> That's the important thing for me.
>
> If workaround was big or ugly I would not do it, but here it's clean(use up
> to date method) and fast and Andrei analyzed it already.
>
>
>
>
>
> Regards
>
> On Wednesday, May 27, 2015, sebb <se...@gmail.com> wrote:
>
>> On 26 May 2015 at 20:17, Philippe Mouawad <philippe.mouawad@gmail.com
>> <javascript:;>> wrote:
>>> Hi,
>>> I think it would be over engineering.
>>> I had previous experience with Class Loader isolation, it is rather
>> complex
>>> and sometimes debugging issues is really not easy.
>>>
>>> I think it is pretty feasible to either follow same dependencies or use
>>> something like jarjar to embed other versions.
>>>
>>> @Andrei, I think it can be considered as a regression in httpmime.
>> Agreed.
>>
>>> Do we agree that if we upgrade httpmime we need to do the change, so
>> let's
>>> fix it.
>> No, I think it should be fixed in httpmime.
>> Or at least that approach should be tried first, because the cause is
>> httpmime and fixing it there will fix it for everyone.
>>
>>> Regards
>>>
>>>
>>>
>>> On Tue, May 26, 2015 at 8:49 PM, Vladimir Sitnikov <
>>> sitnikov.vladimir@gmail.com <javascript:;>> wrote:
>>>
>>>> Can we isolate "in-core" classloaders from plugin classloaders?
>>>>
>>>> For instance, allow a plugin use "per-plugin" class loader, so if the
>>>> plugin author opts-in for her own classloader, then the plugin sees
>>>> just JMeter core files and the jars from the plugin's folder.
>>>>
>>>> That would eliminate "we can't both keep version and upgrade" issues.
>>>>
>>>> Vladimir
>>>>
>>>
>>>
>>> --
>>> Cordialement.
>>> Philippe Mouawad.
>
Re: HTTPClient4 missing filename for file uploads
Posted by Philippe Mouawad <ph...@gmail.com>.
I think for faster fix:
- it should be fixed in jmeter as anyway we use a deprecrated method
(probably removed in future version of httpmime). We can see it as a
workaround but this approach has been taken in the past for httpclient bugs.
- report a bug to httpmime
Otherwise we slow down the fix for our project , seen from customer
perspective of jmeter , the issue is in jmeter.
That's the important thing for me.
If workaround was big or ugly I would not do it, but here it's clean(use up
to date method) and fast and Andrei analyzed it already.
Regards
On Wednesday, May 27, 2015, sebb <se...@gmail.com> wrote:
> On 26 May 2015 at 20:17, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>> wrote:
> > Hi,
> > I think it would be over engineering.
> > I had previous experience with Class Loader isolation, it is rather
> complex
> > and sometimes debugging issues is really not easy.
> >
> > I think it is pretty feasible to either follow same dependencies or use
> > something like jarjar to embed other versions.
> >
> > @Andrei, I think it can be considered as a regression in httpmime.
>
> Agreed.
>
> > Do we agree that if we upgrade httpmime we need to do the change, so
> let's
> > fix it.
>
> No, I think it should be fixed in httpmime.
> Or at least that approach should be tried first, because the cause is
> httpmime and fixing it there will fix it for everyone.
>
> > Regards
> >
> >
> >
> > On Tue, May 26, 2015 at 8:49 PM, Vladimir Sitnikov <
> > sitnikov.vladimir@gmail.com <javascript:;>> wrote:
> >
> >> Can we isolate "in-core" classloaders from plugin classloaders?
> >>
> >> For instance, allow a plugin use "per-plugin" class loader, so if the
> >> plugin author opts-in for her own classloader, then the plugin sees
> >> just JMeter core files and the jars from the plugin's folder.
> >>
> >> That would eliminate "we can't both keep version and upgrade" issues.
> >>
> >> Vladimir
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
--
Cordialement.
Philippe Mouawad.
Re: HTTPClient4 missing filename for file uploads
Posted by sebb <se...@gmail.com>.
On 26 May 2015 at 20:17, Philippe Mouawad <ph...@gmail.com> wrote:
> Hi,
> I think it would be over engineering.
> I had previous experience with Class Loader isolation, it is rather complex
> and sometimes debugging issues is really not easy.
>
> I think it is pretty feasible to either follow same dependencies or use
> something like jarjar to embed other versions.
>
> @Andrei, I think it can be considered as a regression in httpmime.
Agreed.
> Do we agree that if we upgrade httpmime we need to do the change, so let's
> fix it.
No, I think it should be fixed in httpmime.
Or at least that approach should be tried first, because the cause is
httpmime and fixing it there will fix it for everyone.
> Regards
>
>
>
> On Tue, May 26, 2015 at 8:49 PM, Vladimir Sitnikov <
> sitnikov.vladimir@gmail.com> wrote:
>
>> Can we isolate "in-core" classloaders from plugin classloaders?
>>
>> For instance, allow a plugin use "per-plugin" class loader, so if the
>> plugin author opts-in for her own classloader, then the plugin sees
>> just JMeter core files and the jars from the plugin's folder.
>>
>> That would eliminate "we can't both keep version and upgrade" issues.
>>
>> Vladimir
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: HTTPClient4 missing filename for file uploads
Posted by Philippe Mouawad <ph...@gmail.com>.
Hi,
I think it would be over engineering.
I had previous experience with Class Loader isolation, it is rather complex
and sometimes debugging issues is really not easy.
I think it is pretty feasible to either follow same dependencies or use
something like jarjar to embed other versions.
@Andrei, I think it can be considered as a regression in httpmime.
Do we agree that if we upgrade httpmime we need to do the change, so let's
fix it.
Regards
On Tue, May 26, 2015 at 8:49 PM, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> Can we isolate "in-core" classloaders from plugin classloaders?
>
> For instance, allow a plugin use "per-plugin" class loader, so if the
> plugin author opts-in for her own classloader, then the plugin sees
> just JMeter core files and the jars from the plugin's folder.
>
> That would eliminate "we can't both keep version and upgrade" issues.
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: HTTPClient4 missing filename for file uploads
Posted by Vladimir Sitnikov <si...@gmail.com>.
Can we isolate "in-core" classloaders from plugin classloaders?
For instance, allow a plugin use "per-plugin" class loader, so if the
plugin author opts-in for her own classloader, then the plugin sees
just JMeter core files and the jars from the plugin's folder.
That would eliminate "we can't both keep version and upgrade" issues.
Vladimir
Re: HTTPClient4 missing filename for file uploads
Posted by Andrey Pokhilko <ap...@ya.ru>.
I did not raise bug in HttpClient project as it is not a bug, they just
deprecated this constructor.
I'd be happy to not require updated HttpClient, but latest versions of
Selenium require it. And I can't use old Selenium libs because of
support for latest browsers.
Andrey Pokhilko
On 05/26/2015 09:29 PM, Philippe Mouawad wrote:
> 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 <ap...@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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>
Re: HTTPClient4 missing filename for file uploads
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <ap...@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.
Re: HTTPClient4 missing filename for file uploads
Posted by Andrey Pokhilko <ap...@ya.ru>.
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 <ap...@ya.ru> 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 <se...@gmail.com> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
Re: HTTPClient4 missing filename for file uploads
Posted by sebb <se...@gmail.com>.
On 15 May 2015 at 12:41, Andrey Pokhilko <ap...@ya.ru> 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 <se...@gmail.com> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>
Re: HTTPClient4 missing filename for file uploads
Posted by Andrey Pokhilko <ap...@ya.ru>.
It is not a bug in HC, they just deprecated that method since 4.3 and
broke old behavior for deprecated method. 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).
Andrey Pokhilko
On 05/15/2015 02:25 PM, sebb wrote:
> On 15 May 2015 at 12:24, sebb <se...@gmail.com> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
Re: HTTPClient4 missing filename for file uploads
Posted by sebb <se...@gmail.com>.
On 15 May 2015 at 12:24, sebb <se...@gmail.com> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>>
>>
Re: HTTPClient4 missing filename for file uploads
Posted by sebb <se...@gmail.com>.
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.
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 <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>
>
Re: HTTPClient4 missing filename for file uploads
Posted by Andrey Pokhilko <ap...@ya.ru>.
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 <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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
>>>>>>
>>>>>>
>>>>>>
>>
>
Re: HTTPClient4 missing filename for file uploads
Posted by UBIK LOAD PACK Support <su...@ubikloadpack.com>.
AFAIU, setting name would not break existing behaviour and fix the
situation right ?
On Fri, May 15, 2015 at 11:50 AM, Andrey Pokhilko <ap...@ya.ru> 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 <ap...@ya.ru> 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 <ap...@ya.ru> 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
> >>>>
> >>>>
> >>>>
>
>
--
Regards
Ubik Load Pack <http://ubikloadpack.com> Team
Follow us on Twitter <http://twitter.com/ubikloadpack>
Cordialement
L'équipe Ubik Load Pack <http://ubikloadpack.com>
Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
Re: HTTPClient4 missing filename for file uploads
Posted by Andrey Pokhilko <ap...@ya.ru>.
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 <ap...@ya.ru> 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 <ap...@ya.ru> 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
>>>>
>>>>
>>>>
Re: HTTPClient4 missing filename for file uploads
Posted by sebb <se...@gmail.com>.
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 <ap...@ya.ru> 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 <ap...@ya.ru> 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
>>>
>>>
>>>
>
Re: HTTPClient4 missing filename for file uploads
Posted by Andrey Pokhilko <ap...@ya.ru>.
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 <ap...@ya.ru> 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
>>
>>
>>
Re: HTTPClient4 missing filename for file uploads
Posted by sebb <se...@gmail.com>.
On 14 May 2015 at 17:36, Andrey Pokhilko <ap...@ya.ru> 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
>
>
>