HTTP::Daemon::SSL's accept() method is supposed to return false if the IO::Socket times out without a connection (unless the timeout is 0 of course, in which case it will never return). This is in conformance with the documentation for HTTP::Daemon which (on this point) HTTP::Daemon::SSL's documentation does not indicate variance. HTTP::Daemon::SSL does not do this, however, as it has a while(1) loop in it's overridden accept() method.
My problem is this - in fixing this I may break code that uses HTTP::Daemon::SSL and assumes this built-in while loop. I'm not too concerned as any code which also works with HTTP::Daemon will work after this fix, but I'm wondering what people feel the etiquette is in this situation.
For instance, the current version is 1.02 - should I change the version to 2.0 to signify a change in the API (even though the published API doesn't change - the functionality is simply coming into step with the docs)? Are there any other ways I can mitigate impact?
Update: As requested by Corion, here is a code sample. The following code will exit cleanly with a HUP if $daemon is an instance of HTTP::Daemon, but not if it is an instance of HTTP::Daemon::SSL 1.02:
$SIG{HUP} = sub { $__server_should_run = 0; }; $__server_should_run = 1; while ($__server_should_run) { my $conn = $daemon->accept or next; # handle request }
In reply to Correcting/changing a CPAN module interface by aufflick
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |