Bug 40954

Summary: PLACK-ERROR: End of stream encountered while parsing preamble
Product: Koha Reporter: Marcel de Rooy <m.de.rooy>
Component: Architecture, internals, and plumbingAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: dcook
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41154
GIT URL: Initiative type: ---
Sponsorship status: --- Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Marcel de Rooy 2025-10-06 09:46:04 UTC
Found this in the plack-error.log on a 24.11 install:
End of stream encountered while parsing preamble at /usr/share/perl5/HTTP/Entity/Parser/MultiPart.pm line 157.

Grepping for HTTP::Entity::Parser::MultiPart did not give any results.

Anyone have an idea?
Comment 1 Marcel de Rooy 2025-10-06 10:36:52 UTC
Joubu: the error comes from 
/usr/share/perl5/HTTP/MultiPartParser.pm:                    $finish && $on_error->(q/End of stream encountered while parsing preamble/);
Comment 2 Marcel de Rooy 2025-10-06 10:39:44 UTC
(In reply to Marcel de Rooy from comment #1)
> Joubu: the error comes from 
> /usr/share/perl5/HTTP/MultiPartParser.pm:                    $finish &&
> $on_error->(q/End of stream encountered while parsing preamble/);

HTTP::MultiPartParser
This class provides a low-level API for processing MultiPart MIME data streams conforming to MultiPart types as defined in RFC 2616.
Comment 3 Marcel de Rooy 2025-10-30 08:24:59 UTC
Saw a few coming by again. Tracing them down to 'hacking stuff' like:

177.135.23.55 - - [29/Oct/2025:17:19:52 +0000] "POST /admin/categories.php/login.php?cPath=&action=new_product_preview HTTP/1.1" 500 21 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0 Safari/537.36" "library.rijksmuseum.nl:443" "-"

177.135.23.55 - - [29/Oct/2025:17:19:52 +0000] "GET /includes/configure.php HTTP/1.1" 404 28935 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0 Safari/537.36" "library.rijksmuseum.nl:443" "-"

177.135.23.55 - - [29/Oct/2025:17:19:53 +0000] "POST /admin/banner_manager.php/login.php?action=insert HTTP/1.1" 500 21 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0 Safari/537.36" "library.rijksmuseum.nl:443" "-"

177.135.23.55 - - [29/Oct/2025:17:19:53 +0000] "POST /cgi-bin/admin/categories.php/login.php?cPath=&action=new_product_preview HTTP/1.1" 404 28935 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0 Safari/537.36" "library.rijksmuseum.nl:443" "-"

Not sure why the first and third url results in 500 21? But the fourth url in 404 28935, coming from errors/404.pl.
How does an unexisting php trigger a 500 ?

Also I am wondering if we should pass such Apache errors to Plack? It takes just a few hundred bytes to say Not found in about 50 ms with a trivial ErrorDocument but it takes 40K and 500ms to go to errors/404 or 500.pl in Plack.
Shouldnt we reserve the Plack responses for Plack requests (so real perl ones)?
Comment 4 Marcel de Rooy 2025-10-30 08:27:41 UTC
The above is from the nginx log. Plack.log just says:

177.135.23.55 - - [29/Oct/2025:18:19:52 +0100] "GET errors/500.pl HTTP/1.1" 500 21 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0 Safari/537.36"
177.135.23.55 - - [29/Oct/2025:18:19:53 +0100] "GET errors/500.pl HTTP/1.1" 500 21 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0 Safari/537.36"

And Apache:
myclone.rijkskoha.nl:80 177.135.23.55 - - [29/Oct/2025:18:19:52 +0100] "POST /admin/categories.php/login.php?cPath=&action=new_product_preview HTTP/1.0" 500 210 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0 Safari/537.36"
Comment 5 David Cook 2025-10-31 00:00:40 UTC
(In reply to Marcel de Rooy from comment #3)
> Also I am wondering if we should pass such Apache errors to Plack? It takes
> just a few hundred bytes to say Not found in about 50 ms with a trivial
> ErrorDocument but it takes 40K and 500ms to go to errors/404 or 500.pl in
> Plack.
> Shouldnt we reserve the Plack responses for Plack requests (so real perl
> ones)?

I do think about that sometimes. It also takes up valuable Starman process time in general. If you've got some bots sending lots of requests that generate 404s, it doesn't really make sense to hammer your Starman with requests for 404.pl. 

In the past, I've thought about generating static HTML files which could be served from the DocumentRoot, so that Starman isn't being touched and Apache can just do what it does best.
Comment 6 Marcel de Rooy 2025-10-31 10:45:53 UTC
Opened bug 41154 for the ErrorDocument of Apache. This bug keeps focused on the preamble crash.