Better version (backs out most of an incorrect prior change).
On Fri, Nov 4, 2022 at 11:38 AM Joe Schaefer <j...@sunstarsys.com> wrote:
> 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>
>
>
>
--
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,15 +37,14 @@
"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
-"--AaB03x--" CRLF;
-
-/* This (invalid) case used to segfault the parser before r164254 so should
- be tested separately to form_data:
-
-static char form_data_fail[] =
+"--AaB03x" CRLF
"content-disposition: form-data; name=\"\"" CRLF
"content-type: text/plain;" CRLF " charset=windows-1250" CRLF
"content-transfer-encoding: quoted-printable" CRLF CRLF
@@ -52,8 +51,6 @@
"Joe owes =80100." CRLF
"--AaB03x--" CRLF;
-*/
-
static char xml_data[] =
"<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>"
"<methodCall>"
@@ -237,7 +234,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, 4);
val = apr_table_get(body,"field1");
AT_str_eq(val, "Joe owes =80100.");
@@ -560,5 +557,3 @@
return 0;
}
-
-
