You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Adam Brin <ab...@digitalantiquity.org> on 2017/07/14 13:46:50 UTC
Multipart fixes in 2.5.12 and non-file payloads
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:
<constant name="struts.multipart.validationRegex" value="(.*)"/>
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
Re: Multipart fixes in 2.5.12 and non-file payloads
Posted by Lukasz Lenart <lu...@apache.org>.
2017-07-17 17:21 GMT+02:00 Adam Brin <ab...@digitalantiquity.org>:
> 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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multipart fixes in 2.5.12 and non-file payloads
Posted by Adam Brin <ab...@digitalantiquity.org>.
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 <lu...@apache.org> wrote:
>
> 2017-07-17 14:35 GMT+02:00 Adam Brin <ab...@digitalantiquity.org>:
>> 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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multipart fixes in 2.5.12 and non-file payloads
Posted by Lukasz Lenart <lu...@apache.org>.
2017-07-17 14:35 GMT+02:00 Adam Brin <ab...@digitalantiquity.org>:
> 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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Multipart fixes in 2.5.12 and non-file payloads
Posted by Adam Brin <ab...@digitalantiquity.org>.
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 <ab...@digitalantiquity.org>
wrote:
> Hi Lukasz,
> Yes,
>
> - adam
>
> On Sun, Jul 16, 2017 at 11:03 PM, Lukasz Lenart <lu...@apache.org>
> 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 <ab...@digitalantiquity.org>:
>> > 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:
>> >
>> > <constant name="struts.multipart.validationRegex" value="(.*)"/>
>> >
>> > 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-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@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
Posted by Adam Brin <ab...@digitalantiquity.org>.
Hi Lukasz,
Yes,
- adam
On Sun, Jul 16, 2017 at 11:03 PM, Lukasz Lenart <lu...@apache.org>
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 <ab...@digitalantiquity.org>:
> > 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:
> >
> > <constant name="struts.multipart.validationRegex" value="(.*)"/>
> >
> > 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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
_________________________________________________________
Adam Brin
Director of Technology, Digital Antiquity
480.965.1278
Re: Multipart fixes in 2.5.12 and non-file payloads
Posted by Lukasz Lenart <lu...@apache.org>.
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 <ab...@digitalantiquity.org>:
> 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:
>
> <constant name="struts.multipart.validationRegex" value="(.*)"/>
>
> 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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org