Bug#1025769: HTTP::Server::Simple vs. support for Unix domain sockets

[Ivan Shmakov]

>>>>> 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/