in reply to AnyEvent::HTTPD -> Extra Callback after response?

Is maybe your request to /test done twice? I'd add more debug output to the different levels of subroutines.

Replies are listed 'Best First'.
Re^2: AnyEvent::HTTPD -> Extra Callback after response?
by cavac (Prior) on Jun 11, 2021 at 06:14 UTC

    I agree. It also may be helpful to know what program is used to make the request. Browsers, especially Google Chrome, is notorious for opening multiple connections at once "just in case any of them doesn't work".

    For testing basic HTTP stuff, i recommend installing LWP (cpan install LWP). This gives you the nice HEAD script. Then run
    HEAD -E http://localhost:8123/test

    This will dump the headers of the full response chain (e.g. multiple headers if there is a redirect or whatever).

    perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'
Re^2: AnyEvent::HTTPD -> Extra Callback after response?
by sectokia (Friar) on Jun 11, 2021 at 08:57 UTC
    It is not the client requesting twice. It does it even with LWP::Simple getprint. Note: I am running on windows.

    The first sub is only called on on each client connect. The second sub is gets called twice for reason.

    I can get around it as per below, by storing a flag to indicate I've already handled this 'request':

    use strict; use warnings; use AnyEvent::HTTPD; my $h = AnyEvent::HTTPD->new(port => 8123);; my $requests = {}; my $requestCounter = 0; $h->reg_cb ( '/test' => sub { my ($httpd,$req) = @_; my $request = $requestCounter; $requestCounter++; print "Starting request $request\n"; $requests->{$request}->{'state'} = 'new'; $req->respond({ content => ['text/plain', sub { my ($data_cb) = @_; return unless $data_cb; if (($requests->{$request}->{'state'} // 0) ne 'new') { $data_cb->(); return; } $requests->{$request}->{'state'} = 'handled'; print "Setting timer for $request...\n"; $requests->{$request}->{'timer'} = AnyEvent->timer(aft +er => 3, cb => sub { print "Sending response for $request...\n"; $data_cb->("You are request $request"); $data_cb->(); delete $requests->{$request}; return; }); }] }); }, ); my $c = AnyEvent::condvar; $c->recv();

      This seems to be either a timer or timeout+retry problem. If you respond right away, it works as expected.

      use strict; use warnings; use AnyEvent::HTTPD; my $h = AnyEvent::HTTPD->new(port => 8123);; my $requests = {}; my $requestCounter = 0; $h->reg_cb ( '/test' => sub { my ($httpd,$req) = @_; my $request = $requestCounter; $requestCounter++; print "Starting response for ", $req->{method}, " request $req +uest\n"; $req->respond( [200, 'ok', { 'Content-Type' => 'text/html' }, '<h1>Test</h1>' ]); } ); my $c = AnyEvent::condvar; $c->recv();

      Why do you want to wait instead of responding as soon as possible?

      If you want to wait for an event to happen, the modern way is to either use Websockets or Push notifications. If you can't do either of those (please explain why), then the proper fallback to handle this would be cyclic calls from client to server to "pull" not yet handled events.

      Leaving standard GET requests just "hanging" will lead to a number of different things:

      • Wasted resources on the server
      • Timeouts
      • Modern browsers marking the connection to your server as unreliable, therefore increasing the number of parallel TCP connections they will open to try and get a result.
      • Customer complaints
      • Getting shouted at by your system administrator

      perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'
        Wait is just an example of async. Instead of wait, I would be doing something such as, comms request to another server to fetch resources need to form the response. Basically I have a 'sync' function (Where I respond immediately) and in this example I am trying to make a async function, where I respond to the request later when I have the data available. I am going to dig into the code to see if I can figure out why it triggers twice, for now my 'fix' is to just to store a flag for each request instance so indicate I've already handled it