Re: Multipart fixes in 2.5.12 and non-file payloads

[Lukasz Lenart]

2017-07-17 17:21 GMT+02:00 Adam Brin :
> Our build testing is automated, so if it’s a matter of pulling in a maven 
> artifact and kicking off a build, i’m willing. Otherwise, I’m happy to share 
> a bit of what we do on the testing front to integrate into the automated 
> testing that’s part of struts.

That would be superb cool :) Also if you could share the bit of what
you do - maybe I will finally add some tests to the struts-examples :)


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Multipart fixes in 2.5.12 and non-file payloads

[Adam Brin]

Our build testing is automated, so if it’s a matter of pulling in a maven 
artifact and kicking off a build, i’m willing. Otherwise, I’m happy to share a 
bit of what we do on the testing front to integrate into the automated testing 
that’s part of struts.


-- 
_
Adam Brin
Director of Technology, Digital Antiquity
480.965.1278

> On Jul 17, 2017, at 6:16 AM, Lukasz Lenart  wrote:
> 
> 2017-07-17 14:35 GMT+02:00 Adam Brin :
>> In the automated testing we run on our application there was not one test
>> that passed that used a browser backend be it Chrome or HtmlUnit without
>> adjusting the regular expression.
> 
> Is there a way to involve you and your testing in a new release
> process? I'm always publishing a test build to allow everybody test it
> before we will vote on it. This gives users an opportunity to stop the
> release process and point out what have to be fixed before we can
> start over the release process.
> 
> 
> Regards
> -- 
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
> 


-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Multipart fixes in 2.5.12 and non-file payloads

[Lukasz Lenart]

2017-07-17 14:35 GMT+02:00 Adam Brin :
> In the automated testing we run on our application there was not one test
> that passed that used a browser backend be it Chrome or HtmlUnit without
> adjusting the regular expression.

Is there a way to involve you and your testing in a new release
process? I'm always publishing a test build to allow everybody test it
before we will vote on it. This gives users an opportunity to stop the
release process and point out what have to be fixed before we can
start over the release process.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: Multipart fixes in 2.5.12 and non-file payloads

[Adam Brin]

In the automated testing we run on our application there was not one test
that passed that used a browser backend be it Chrome or HtmlUnit without
adjusting the regular expression.

On Mon, Jul 17, 2017 at 5:29 AM, Adam Brin 
wrote:

> Hi Lukasz,
>   Yes,
>
> - adam
>
> On Sun, Jul 16, 2017 at 11:03 PM, Lukasz Lenart 
> wrote:
>
>> I assume that this is the related ticket to this [1], right?
>>
>> [1] https://issues.apache.org/jira/browse/WW-4818
>>
>> 2017-07-14 15:46 GMT+02:00 Adam Brin :
>> > We have a number of API components that include a textBody as part of
>> the
>> > multipart request.  In 2.5.12, these requests are being kicked out
>> (while
>> > in 2.5.10 they were fine.  changing the constant:
>> >
>> > 
>> >
>> > to allow anything (as in the example) seems to fix the issue, but this
>> > seems imprudent.  This is the code that's making the  API call, which
>> seems
>> > harmless enough:
>> >
>> >   // using the
>> > org.apache.http.entity.mime.MultipartEntityBuilder
>> >
>> > MultipartEntityBuilder builder = MultipartEntityBuilder.create(
>> );
>> >
>> > builder.addTextBody("record", docXml, ContentType.create(
>> > "application/xml", Consts.UTF_8));
>> >
>> > builder.addTextBody(ACCOUNT_ID, accountId.toString());
>> >
>> > HttpPost post = new HttpPost(baseUrl + API_INGEST_UPDATE_FILES);
>> >
>> > post.setEntity(builder.build());
>> >
>> > CloseableHttpResponse response = getHttpClient().execute(post);
>> >
>> >
>> > In looking deeper, (with the http requests on trace, we see multipart
>> > boundaries of:
>> >
>> >  Content-Type: multipart/form-data; boundary=BRKIypZ3Stvuclu7C*-*
>> > CTbP2fNljGAOVk[\r][\n]
>> >
>> >
>> > It looks like the RFC does include hyphens in the boundaries too:
>> > https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html though I'm less
>> > sure about other characters.  I worry this default regex will likely
>> trip
>> > up lots of uploads silently,
>> > --
>> > _
>> > Adam Brin
>> > Director of Technology, Digital Antiquity
>> > 480.965.1278
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
>> For additional commands, e-mail: user-h...@struts.apache.org
>>
>>
>
>
> --
> _
> Adam Brin
> Director of Technology, Digital Antiquity
> 480.965.1278 <(480)%20965-1278>
>



-- 
_
Adam Brin
Director of Technology, Digital Antiquity
480.965.1278

Re: Multipart fixes in 2.5.12 and non-file payloads

[Adam Brin]

Hi Lukasz,
  Yes,

- adam

On Sun, Jul 16, 2017 at 11:03 PM, Lukasz Lenart 
wrote:

> I assume that this is the related ticket to this [1], right?
>
> [1] https://issues.apache.org/jira/browse/WW-4818
>
> 2017-07-14 15:46 GMT+02:00 Adam Brin :
> > We have a number of API components that include a textBody as part of the
> > multipart request.  In 2.5.12, these requests are being kicked out (while
> > in 2.5.10 they were fine.  changing the constant:
> >
> > 
> >
> > to allow anything (as in the example) seems to fix the issue, but this
> > seems imprudent.  This is the code that's making the  API call, which
> seems
> > harmless enough:
> >
> >   // using the
> > org.apache.http.entity.mime.MultipartEntityBuilder
> >
> > MultipartEntityBuilder builder = MultipartEntityBuilder.create(
> );
> >
> > builder.addTextBody("record", docXml, ContentType.create(
> > "application/xml", Consts.UTF_8));
> >
> > builder.addTextBody(ACCOUNT_ID, accountId.toString());
> >
> > HttpPost post = new HttpPost(baseUrl + API_INGEST_UPDATE_FILES);
> >
> > post.setEntity(builder.build());
> >
> > CloseableHttpResponse response = getHttpClient().execute(post);
> >
> >
> > In looking deeper, (with the http requests on trace, we see multipart
> > boundaries of:
> >
> >  Content-Type: multipart/form-data; boundary=BRKIypZ3Stvuclu7C*-*
> > CTbP2fNljGAOVk[\r][\n]
> >
> >
> > It looks like the RFC does include hyphens in the boundaries too:
> > https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html though I'm less
> > sure about other characters.  I worry this default regex will likely trip
> > up lots of uploads silently,
> > --
> > _
> > Adam Brin
> > Director of Technology, Digital Antiquity
> > 480.965.1278
>
> -
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>
>


-- 
_
Adam Brin
Director of Technology, Digital Antiquity
480.965.1278

Re: Multipart fixes in 2.5.12 and non-file payloads

[Lukasz Lenart]

I assume that this is the related ticket to this [1], right?

[1] https://issues.apache.org/jira/browse/WW-4818

2017-07-14 15:46 GMT+02:00 Adam Brin :
> We have a number of API components that include a textBody as part of the
> multipart request.  In 2.5.12, these requests are being kicked out (while
> in 2.5.10 they were fine.  changing the constant:
>
> 
>
> to allow anything (as in the example) seems to fix the issue, but this
> seems imprudent.  This is the code that's making the  API call, which seems
> harmless enough:
>
>   // using the
> org.apache.http.entity.mime.MultipartEntityBuilder
>
> MultipartEntityBuilder builder = MultipartEntityBuilder.create();
>
> builder.addTextBody("record", docXml, ContentType.create(
> "application/xml", Consts.UTF_8));
>
> builder.addTextBody(ACCOUNT_ID, accountId.toString());
>
> HttpPost post = new HttpPost(baseUrl + API_INGEST_UPDATE_FILES);
>
> post.setEntity(builder.build());
>
> CloseableHttpResponse response = getHttpClient().execute(post);
>
>
> In looking deeper, (with the http requests on trace, we see multipart
> boundaries of:
>
>  Content-Type: multipart/form-data; boundary=BRKIypZ3Stvuclu7C*-*
> CTbP2fNljGAOVk[\r][\n]
>
>
> It looks like the RFC does include hyphens in the boundaries too:
> https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html though I'm less
> sure about other characters.  I worry this default regex will likely trip
> up lots of uploads silently,
> --
> _
> Adam Brin
> Director of Technology, Digital Antiquity
> 480.965.1278

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org