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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>
