in reply to Re^2: Dancer::send_file only for POST?
in thread Solved: Dancer::send_file doesn't work with POST? ( Angular JS hijacks the response)

I'm sorry to be so snarky, but as I've already asked you to provide more detail, I'll quote your signature here:

The way forward always starts with a minimal test.

Please, do provide us with a minimal example that we can use to reproduce your case. Also tell us what PSGI webserver you're using. Different webservers have different features and maybe the webserver your're using tries to be smart about sending files by delegating this task to the operating system by name.

Some of the tests seem to allow send_file( \$data, ... ), so maybe you're not filling $data properly in the GET case? A short example should help us help you better here.

Replies are listed 'Best First'.
Re^4: Dancer::send_file only for POST?
by 1nickt (Canon) on Nov 11, 2015 at 14:24 UTC

    Hi Corion, apologies, it is 0500 and I was posting on phone. Back at PC now.

    This is a Dancer app running nicely with starman.

    This code results in the browser downloading a CSV file: 

    get '/test/csv' => sub {
    my $csv = "foo, bar, baz";
    send_file( \$csv, content_type => 'text/csv', filename => 'qux.csv
+' );
};

    [download]
    While this code results in nothing: no error in the log, no content returned to browser: 
    post '/test/csv' => sub {
    my $csv = "foo, bar, baz";
    send_file( \$csv, content_type => 'text/csv', filename => 'qux.csv
+' );
};

    [download]

    I am using POST since the request is made from JS which knows about the user's environment.

    The way forward always starts with a minimal test.
[reply]
[d/l]
[select]

      Thanks for your example. I had originally misunderstood your post in that it seemed that POST works but GET fails. But from reading your code, it seems to be the other way around.

      I found Dancer diagnostics to be horrible and do not trust its log anymore. Have you made sure that warnings do not get treated as fatal by Dancer? Maybe trace that the POST handler actually gets invoked by doing print-debugging.

      If all else fails, redirect to a GET handler from your POST handler:

      post '/test/csv' => sub {
    return redirect '/test/csv';
};

      [download]
[reply]
[d/l]
[select]

        Thanks Corion. The confusion in the OP was entirely my fault.

        I implemented a redirect but the result is the same: the print statement, which I placed immediately before the redirect, is output but then nothing in browser or log.

        The way forward always starts with a minimal test.
[reply]
[d/l]

In Section Seekers of Perl Wisdom