Please add this additional regression test (for the mfd parser with empty
parts).
On Fri, Nov 4, 2022 at 11:12 AM Joe Schaefer <j...@sunstarsys.com> wrote:
> What's in HEAD as of now looks promising. I'll be happy to dogfood this
> once we're in the candidacy stage.
> The point of having apreq in trunk isn't just for mod_perl, but for anyone
> who wants to take web application development
> seriously from the apache module viewpoint. It ticks all the boxes:
> thread-safe, subrequest-friendly, and is mostly
> easy to use. It just needs to be refined and matured to the point where
> the quality controls necessary for shipping in httpd3
> are at a comfortable level for httpd developers. If there's a lot more to
> do, reach out privately to discuss. Otherwise,
> lean on me for whatever peer review is missing from the normal release
> cycles for libapreq2 as you see fit. I can't promise
> how long you have my attention, but for the next few releases I'll try to
> participate in the vetting process.
>
>
>
>
>
> On Wed, Nov 2, 2022 at 10:22 AM Joe Schaefer <j...@sunstarsys.com> wrote:
>
>>
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> ------------------------------
>> *From:* Yann Ylavic <ylavic....@gmail.com>
>> *Sent:* Wednesday, November 2, 2022 9:47 AM
>> *To:* dev@httpd.apache.org <dev@httpd.apache.org>
>> *Cc:* Joe Schaefer <j...@sunstarsys.com>
>> *Subject:* Re: [libapreq2] nits to pick about the patches to util.c over
>> the past few years
>>
>> On Mon, Oct 31, 2022 at 7:44 PM Joe Schaefer <j...@sunstarsys.com> wrote:
>> >
>> > The reason this took so long for the community to diagnose isn't
>> because of ill-intent, but because it constituted
>> > a change of behavior in the parser logic that wasn't surfaced in the
>> Changes file.
>>
>> Please review r1905018 (with a CHANGES entry this time), along with
>> r1905019 and r1905020 eventually.
>> I'd suggest subscribing to c...@httpd.apache.org (if not already) and
>> filter/mark subjects with "/httpd/apreq" if you don't want to miss
>> anything.
>>
>> >
>> > There is never going to come a time when there is any need for urgent
>> action on apreq- if it was easy to zero-day
>> > it, it would have happened by now. Thus, take as much time as you need
>> between releases to communicate with
>> > the community about the nature of the deltas you intend to ship with
>> any GA release. You have my email address
>> > if you need to spitball any patchsets you are toying with; it's a lot
>> less painful to get my input in advance than after the fact.
>>
>> That's not how it usually works though: r1895107 is dated "Nov 17,
>> 2021", the [VOTE] for v2.17 started "Aug 18, 2022" and ended Aug 25,
>> which left you 8 months to review the changes in trunk (and chime
>> in..).
>>
>> There’s nothing usual about this situation, Yann. I’ve retired from the
>> foundation many years ago.
>> I’m here now because of the hatchet job in the 2.17 announce and CVE
>> description, and resulting need for me to parachute back in again to assist.
>>
>> If you want me in person to review something, for your own benefit as
>> someone who deals in apreq, I’m happy to. That will instantly drop any
>> charges of treating users like Guinea pigs, and also mean I will be more
>> respectful of your work overall.
>>
>>
>> Regards;
>> Yann.
>>
>
>
> --
> Joe Schaefer, Ph.D.
> We only build what you need built.
> <j...@sunstarsys.com>
> 954.253.3732 <//954.253.3732>
>
>
>
--
Joe Schaefer, Ph.D.
We only build what you need built.
<j...@sunstarsys.com>
954.253.3732 <//954.253.3732>
Index: t/parsers.c
===================================================================
--- t/parsers.c (revision 1905068)
+++ t/parsers.c (working copy)
@@ -37,6 +37,10 @@
"content-transfer-encoding: quoted-printable" CRLF CRLF
"Joe owes =80100." CRLF
"--AaB03x" CRLF
+"content-disposition: form-data; name=\"\"; filename=\"\"" CRLF
+"Content-Type: text/plain" CRLF CRLF
+"... contents of empty parts ..." CRLF CRLF
+"--AaB03x" CRLF
"content-disposition: form-data; name=\"pics\"; filename=\"file1.txt\"" CRLF
"Content-Type: text/plain" CRLF CRLF
"... contents of file1.txt ..." CRLF CRLF
@@ -44,7 +48,7 @@
/* This (invalid) case used to segfault the parser before r164254 so should
be tested separately to form_data:
-
+
static char form_data_fail[] =
"content-disposition: form-data; name=\"\"" CRLF
"content-type: text/plain;" CRLF " charset=windows-1250" CRLF
@@ -237,7 +241,7 @@
AT_int_eq(rv, (j < strlen(form_data)) ? APR_INCOMPLETE :
APR_SUCCESS);
rv = apreq_parser_run(parser, body, tail);
AT_int_eq(rv, APR_SUCCESS);
- AT_int_eq(apr_table_elts(body)->nelts, 2);
+ AT_int_eq(apr_table_elts(body)->nelts, 3);
val = apr_table_get(body,"field1");
AT_str_eq(val, "Joe owes =80100.");
@@ -560,5 +564,3 @@
return 0;
}
-
-
