the unfiltered log is usually what is meant. but i think things will boil down to a
limitation on the size of the payload.
as the server appears to be yours, presumably you could increase (or remove a
limitation to) the payload size.
putbytes() reveals the size of the byte array up front. this would trigger an immediate
reaction of some sort. broken pipe appears to have popped up first, but i'm pretty
sure you'll find that the file is too big to put as a block. (how the server chooses to
deal with 16mb of data would determine whether or not it sets a size limit.)
a way around this is chunked data. the protocol is very simple, but it's
not going to work with the current version of httputils. the principal difference
between chunked and not chunked is that chunked data does not indicate the size
of the payload prior to the transfer (it does have to indicate the size of each
you will need to implement the http protocol yourself (simple) and figure out a
way either to allow network activity on the main thread or implement a thread to
perform the transfer. there is a handy inline snippet for that by erel somewhere
even if you can enable network activity on the main thread, android might still pull
the plug on a 16mb file if it locks up the gui for too long. matters such as the http
protocol and background threads are hidden from us thanks to httputils.
i chose to address the issue with inline java (a network connection on a background
thread mimicking the http protocol for encoding chunked data). you might be able
to accomplish the same thing in b4a with sockets or async streams, but you'll have to
implement the protocol yourself. i'm just more comfortable inline (even though i'm
essentially re-inventing the wheel since many b4a libraries that do the same work
are already available to us if one takes the time to learn them).
what do you think you can handle?