Re: [Klara FreeBSD #2159] Second bug in our web server: mod_perl2 Apache2::Upload upload method silently dies

	No worries.  I'm glad you included [email protected] in this 
development of software that is important to mod_perl2.

	I'm curious though, why not upgrade the libapreq2 package in the 
FreeBSD ports/pacakges system to libapreq2 v2.18, which already 
resolved the problem, instead of creating a different branch of v2.17 
(along with the additional effort that entails)?

	Or is there something about libapreq2 v2.18 that creates other 
problems that makes it the wrong candidate?

	Thanks.

> I am very sorry, I did not remove [email protected] from my email 
> to Klara systems. This was not intended for the list.
> 
> To answer your question, I don't want to compile and install from 
> source, although I could, I would prefer to use the FreeBSD ports / 
> packages system.
> 
> 
> On 7/22/25 12:01, [email protected] wrote:
> > 	Why is effort being put into patching libapreq2 v2.17 when simply
> > compiling v2.18 from source already solves the problems?
> >
> > > We now know how to fix this problem. The installation I have for tes=
ting mixes
> > > packages from poudriere and ports installed from /usr/ports, which i=
s not best
> > > practice. The question is how to apply a fix in production in the "r=
ight" way?
> > >
> > > A) make a poudriere based on an older snapshot of the ports tree tha=
t includes
> > > libapreq2 version 2.16. I am 85% sure that the bug was introduced in=
 2.17.
> > > Build only the libapreq2 package (which unfortunately has a lot of
> > > dependencies, including Apache itself), then have a repo pointing to=
 that with
> > > priority higher than FreeBSD default "Latest" as well as higher than=
 our own
> > > current "Latest" poudriere. The problem with this approach is we wil=
l end up
> > > with an older version of Apache and a lot of other important package=
s.
> > >
> > > B) Klara convinces [email protected] (mailto:[email protected]) to=
 put out an
> > > official upgrade in the ports tree version 2.17_1 with the patch tha=
t Xavier
> > > created
> > >
> > > C) We create a poudriere with Xavier's patch applied to libapreq2, o=
r rather
> > > apply the patch to our existing "default" poudriere. I don't know ho=
w to do
> > > that, but it seems like a use case poudriere must have been designed=
 for.
> > >
> > > D) I use my existing mix of ports & packages in prod, perhaps with s=
ome pkg
> > > lock, on the grounds that we know it works and we can roll forward t=
o a better
> > > solution when one comes out soon. I have done worse things in the pa=
st.
> > >
> > > I hope this makes sense.
> > >
> > > - Alex
> > >
> > >
> > > On 7/18/25 19:31, Alex Aminoff wrote:
> > >
> > >   I did this, and I believe it has fixed the problem!
> > >
> > >   You can test this here
> > >
> > >   http://backdev.nber.org/uploadtest
> > >
> > >   What I did was apply your patch in /usr/ports on our diskless root
> > >   FreeBSD-14.2-root-202507, after running make extract in www/libapr=
eq2. Then
> > >   I had to re-compile in ports mod_perl and p5-libapreq2 and some ot=
her
> > >   stuff, and install those from ports.
> > >
> > >   root@bsdalt:/usr/ports/www/p5-libapreq2 # pkg info | grep apreq
> > >   libapreq2-2.17_1 Generic Apache2 Request Library
> > >   p5-libapreq2-2.17 Perl binding for the Generic Apache2 Request Lib=
rary
> > >
> > >   Now the next question is what is the best way to have this "in pro=
duction".
> > >   Can we apply your patch in some sensible way on poudriere? Or will=
 you
> > >   contact the libapreq2 maintainers and try to get it accepted there=
?
> > >
> > >   Also, there is now a weird problem where /usr/local/etc/rc.d/apach=
e24
> > >   always takes a really long time to run, like a minute. I need to t=
rack down
> > >   what is slowing it down.
> > >
> > >   - Alex
> > >
> > >
> > >   On 7/18/25 02:22, Xavier Beaudouin wrote:
> > >
> > >     Hello Alex,
> > >     I made a try to integrate the 3 commits into current port.
> > >     Can you have a try on your side, with the following patch (from =
current
> > >     port tree)?
> > >     Kind regards,/Xavier
> > >
> > >       Le 18 juil. 2025 =E0 03:06, Alex Aminoff
> > >       <[email protected]> (mailto:support.freebsd@kla=
rasystems.com)
> > >       a =E9crit :
> > >       Ticket URL:
> > >       https://support.klarasystems.com/Ticket/Display.html?id=3D2159=
 (https://support.klarasystems.com/Ticket/Display.html?id=3D2159)
> > >
> > >       I did a bit of googling and found this unfortunately rather
> > >       vitriolic thread
> > >
> > >       https://lists.apache.org/[email protected]:2024-2:apre=
q
> > >
> > >       I could not quite follow which of those people if any are the
> > >       nominal maintainers of apreq. Patches to the current version m=
ight
> > >       be a way forward. OTOH maybe the maintainers of the FreeBSD po=
rt
> > >       know some of those people or are some of those people and are =
aware
> > >       of or involved in the politics?
> > >
> > >       - Alex
> > >
> > >
> > >       On 7/17/25 15:58, Allan Jude wrote:
> > >
> > >         There only appear to be 3 changes since 2.17, all from 2023.
> > >
> > >         The first one talks specifically about a regression in 2.17,
> > >         and restoring the behaviour from 2.16
> > >
> > >         Might be the one
> > >
> > >
> > >         Allan Jude
> > >         --
> > >         Principal Solutions Architect @ Klara Inc.
> > >         W: klarasystems.com (https://klarasystems.com/)
> > >         M: +1 289-260-5944
> > >
> > >
> > >         On 2025-07-17 3:54 p.m., Kyle Evans wrote:
> > >
> > >           Ticket URL:
> > >           https://support.klarasystems.com/Ticket/Display.html?id=3D=
2159 (https://support.klarasystems.com/Ticket/Display.html?id=3D2159)
> > >
> > >           Hi,
> > >
> > >           If we knew which commits from libareq2 fix it, we could tr=
y
> > >           to convince the port maintainer to accept them as patches
> > >           to the current version if they don't want to hop to a
> > >           snapshot of a development version -- assuming the patches
> > >           aren't incredibly invasive.
> > >
> > >           Thanks,
> > >
> > >           Kyle Evans
> > >
> > >           On 7/17/25 14:52, Alex Aminoff wrote:
> > >
> > >             Ticket URL:
> > >             https://support.klarasystems.com/Ticket/Display.html?id=3D=
2159 (https://support.klarasystems.com/Ticket/Display.html?id=3D2159)
> > >
> > >             On 7/17/25 15:23, Alex Aminoff wrote:
> > >             >
> > >             > Meanwhile I will try wrapping upload() in an eval.
> > >             >
> > >             I tried this, and it is successful in that it returns co=
ntrol to the
> > >             perl code, but the result of the upload call is undef. A=
s I demonstrated
> > >             in my initial post, if there are multiple file fields, a=
ny of them being
> > >             un-filled triggers the bug, so I can not get the info fo=
r the file the
> > >             user actually uploaded.
> > >
> > >             Therefore one possible way forward will indeed be to dow=
nload the
> > >             bleeding edge libapreq2 from source and compile and inst=
all it. I can do
> > >             that, or you could. But please if you can do some more i=
nvestigation first.
> > >
> > >              =A0- Alex
> > >
> > >
> > >
> > >           --
> > >           Kyle Evans
> > >           FreeBSD Engineering Manager, Klara Inc.
> > >
> > >
> > >     Xavier Beaudouin-System Engineer @ Klara Inc.W: klarasystems.com=
 (http://klarasystems.com)
> > >
> > >
> >
> >
> > Randolf Richardson, CNA [email protected]
> > Inter-Corporate Computer & Network Services, Inc.
> > Beautiful British Columbia, Canada
> > https://www.inter-corporate.com/
> >
> >


Randolf Richardson, CNA - [email protected]
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
https://www.inter-corporate.com/