https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8437
--- Comment #34 from David Cook <[email protected]> --- (In reply to David Cook from comment #33) > As Dobrica mentioned, it does appear that Starman is buffering the whole > response before sending it. I am guessing this is due to our usage of > Plack::App::CGIBin... but I'll investigate further. If I understand correctly, this will never work for us, so long as we're using Plack::App::CGIBin to serve export.pl. At https://metacpan.org/release/Plack/source/lib/Plack/App/CGIBin.pm#L47, Plack::App::CGIBin uses Plack::App::WrapCGI. Plack::App::WrapCGI uses CGI::Emulate::PSGI at https://metacpan.org/source/Plack::App::WrapCGI#L87. CGI::Emulate::PSGI writes the response to a temporary file before returning the response (as per https://metacpan.org/release/CGI-Emulate-PSGI/source/lib/CGI/Emulate/PSGI.pm#L19). If you look at CGI::Emulate::PSGI::Streaming (https://metacpan.org/release/CGI-Emulate-PSGI-Streaming/source/lib/CGI/Emulate/PSGI/Streaming.pm), you can see how that handler returns a closure rather than a tuple (as noted at http://www.catalystframework.org/calendar/2013/10). In order to do a streaming response, you need to leverage that $responder coderef in the closure. Of course, this should be doable. I have an idea germinating. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
