handle post redirect manually (#18)

[qcasey]

Nice, this (#18) is looking really good so far. I've only run into one compatibility issue - Are you able to upload documents with the app's camera/scanner?

When doing the POST request, I'm getting a 302 error that Dio isn't able to redirect.

This SO answer pointed to Flutter HttpClientRequest followRedirects property - my quick understanding is that Dart cannot handle 302 POST redirects?

In that case, I think the 302 response should be handled manually. Please take a look at let me know if you're seeing the same, and if you agree that this is the fix.

Using the built in scanner also doesn't set DPI, but I'll file a different issue for that, looks like that might be harder.

Thanks for all your help making paperless-ng compatible :smiley:

[bauerj]

Whoops, you're right, I forgot to test this!

Looks like you're also right that a 302 in a POST doesn't lead to a new POST automatically.

I haven't tested your solution yet but as far as I can see this would send the file twice when NG is used. Is that correct?

One way to improve this further then is to save the "flavour" of the server implementation in FlutterSecureStorage whenever the documents list is parsed and use that to guess the right URL. That should be right most of the time and otherwise we could still use your code to try the other URL.

What do you think? 😊

[qcasey]

That first POST is never redirected, so the file doesn't show up in Paperless-NG until the second request to the API.

Although you may be right, saving the flavour might be the way to go long term. It could account for different versions of the ng API as well.

Totally up to you though, I wanted to propose a solution that fit within your existing structure 👍

[bauerj]

That first POST is never redirected, so the file doesn't show up in Paperless-NG until the second request to the API.

Yes, you're right. I was more concerned about wasted bandwidth. This would be a problem if you used a mobile network with limited bandwidth.

[jonaswinkler]

Oh right. Since you'd upload the document twice and the /push/ endpoint just tells you to please go elsewhere instead of doing anything. I don't know, maybe I can get the backend to just use the same implementation for both endpoints. (Edit: no can do, sorry.) However, ultimately I feel that having everything primarily sitting beneath /api/... is the way to go.

[bauerj]

Yeah, no problem. It shouldn't be too hard for the app to keep track of the server implementation. Since that isn't likely to change that often, we would use the right endpoint most of the time.

[qcasey]

I was more concerned about wasted bandwidth. This would be a problem if you used a mobile network with limited bandwidth.

Oh I see. Then this definitely isn't right, we should do what you suggested.

[bauerj]

Would you open another PR with changes as outlined above? It only takes slight modifications of your code I guess. I could also implement it but not this weekend.

[qcasey]

Yeah no worries, I'll take care of it with a different PR.

Once uploading is working fine I'll put together another with the share sheet functionality we were talking about.

[bauerj]

Thanks, I'm looking forward to it!