the server closed before I choose download in my phone's browser. about qrcp

[tssva]

The parallel-downloads branch on my fork fixes this issue. At least for ZXing. In my testing it has also been successful in allowing parallel downloads to succeed while still allowing for auto-closing. I need more testing to be done. So far the parallel downloads have only been tested using Chrome 65 on Android. Also as is it allows multiple clients to connect and when the first one completes a download the application exits. I have an idea on how to fix it, but would like to have more people test the parallel downloading to make sure I'm on the right track before investing more.

Time constraints mean I won't be able to get a PR submitted until probably tomorrow, but feel free to grab it from my fork.

[tssva]

Found a couple of issues with the code. As is it does happen to allow the transfer to complete sometimes but not consistently. Know the issue and will be updating the code today.

[joyme123]

see this pr

[dochne]

I can confirm that this fixes the issue for me 👍

[dochne]

In the case of some barcode scanning applications, the app will do it's own internal fetch to the URL rather than directly referring you to the browser.

This seems to be the case with the commonly used Barcode Scanner application on Android, and I suspect it may be done automatically by most apps that use the library that it seems to be using underneath, Zxing

I suspect the best way of handling this is to either put in some kind of "don't auto close flag" or the more hacky but potentially more useful not closing the connection depending on the user-agent of the initial request.

[claudiodangelis]

As I mentioned in this comment, I would like to retain the auto close ability. Let's continue researching a solution, I'm pretty sure we will find one; thanks for showing interest in this!

[beac0n]

@claudiodangelis I'm having the same Issue.
I agree, that the feature of auto closing should not be removed.
However, couldn't we add a command line parameter which disables the auto-close feature?
That way the user can decide for themselfs what to use

[claudiodangelis]

Agreed @beac0n, while we work out a definitive fix for this, we can have a flag that prevents the tool from automatically closing.

The patch would look like this:

var autocloseFlag = flag.Bool("autoclose", true, ".....") 

. . .

if *autocloseFlag == true {
    os.Exit(0)
}

Usage would be:

./qr-filetransfer -autoclose=false myfile.pdf

Thoughts? Maybe we can find a better flag name for autoclose (or using a complement)?

To @joyme123: you submitted a PR for this issue a few days back, do you want to apply these changes?

[claudiodangelis]

Hello @ginhton @Dolondro @beac0n and @jerson, could you please help testing the fix provided by @tssva?

Instructions:

# From the cloned repository...
git fetch origin pull/54/head:parallel-downloads
git checkout parallel-downloads
go build
./qr-filetransfer /path/to/the/problematic/file

Thanks 👍