>>>>> On 2022-12-09 02:11:07 +0100, gregor herrmann wrote: >>>>> On Thu, 08 Dec 2022 20:07:38 +0000, Ivan Shmakov wrote:
>> Attempting to implement Unix domain socket support by subclassing >> HTTP::Server::Simple uncovered several issues with the latter, >> which I’m going to describe in this report. (Feel free to clone >> it and address them separately as you see fit.) > Thanks for your bug report. > I’m afraid to say that it mostly is not actionable from the > Debian packaging side. What you propose, in my understanding, > are massive changes to the code, and that’s not what we are > going to do on our own in Debian, but something which needs > to be discussed with upstream and needs to happen there. Not all of the changes I propose are what I’d call ‘massive.’ To summarize: (peer_identify): New method, split off (_process_request): this one. Fixed: only call sockaddr_in on the remote address if its family is AF_INET (was: whenever the family is not AF_INET6.) (listener_handle): New method, allowing for per-instance listener sockets (was: using a single HTTPDaemon filehandle.) (restart): Fixed: supply $^X as an indirect object to exec if $0 is not executable (was: using $0 unconditionally.) (setup): Fixed: use (same as above) for peeraddr example value (was: suggesting that peername can be a hostname while peeraddr cannot.) Mention explicitly in the prose that both peername and peeraddr are currently the same string value representing the remote IPv6 or IPv4 address, and that the code never attempts (potentially time-consuming) reverse DNS calls. Of the above, the first change is the most important for my use case, and even if implemented only partially: (_process_request): Fixed: only call sockaddr_in on the remote address if its family is AF_INET (was: whenever the family is not AF_INET6.) it would still be helpful. The second change is the most invasive. And the rest seem straightforward bugfixes, with the exec one being one-liner. > I can forward your ideas upstream I’d appreciate that. > but it might be easier if you do it yourself as this will > potentially require discussion: > https://github.com/bestpractical/http-server-simple I have no Github account (and I’d rather keep it that way.) I have a CPAN account, though, so I can report the issues to the CPAN RT instance [1], if the upstream monitor that. [1] http://rt.cpan.org/Public/Dist/Display.html?Name=HTTP-Server-Simple >> So far as I can tell, it’s perfectly possible to subclass and >> use HTTP::Server::Simple without libcgi-pm-perl, except perhaps >> with Net::Server (I’m not familiar with the latter and won’t >> claim understanding of what the run method does in the case >> net_server is supplied.) >> The Recommends: relation seems like a better fit in this case: > That’s something relevant for packaging; but I’m not so sure about > your conclusion. After looking around a bit I think I can say > that lib/HTTP/Server/Simple/CGI.pm needs CGI.pm; libcgi-pm-perl > needs to be in Build-Depends-Indep, otherwise the tests fails > (which was not your point); moving libcgi-pm-perl from Depends to > Recommends does not break autopkgtests so it would be ok at first > sight, the question is if we want to ensure an always working > HTTP::Server::Simple::CGI. In the end I guess a Recommends would > be arguable but it’s not that clear-cut IMO … IME it rarely is. The caveat here is that all the packages that depend on libhttp-server-simple-perl /and/ use HTTP::Server::Simple::CGI would need to be updated to depend on libcgi-pm-perl as well. Another alternative is to put HTTP::Server::Simple::CGI into its own binary package, with the dependencies declared as follows: Package: libhttp-server-simple-perl Depends: perl:any Recommends: libhttp-server-simple-cgi-perl Package: libhttp-server-simple-cgi-perl Depends: libcgi-pm-perl, libhttp-server-simple-perl It doesn’t avoid the need to check and possibly update all of the depending packages, though. -- FSF associate member #7257 http://am-1.org/~ivan/