Android Question PostFile in OK Httputils2 (2.92) starts a GET method not POST method

[labcold]

I have been running two systems, transferring files from B4A to B4J, with the same code for over a year without any issues. I have just updated to B4A 10.2 from 9.8 (reluctantly) to solve another issue and now this process is not working anymore.

The code is basically the tutorial example '

[Server] Upload files from your B4A app to your B4J server over the internet

' and if I run that as is then I get the same issue as well.

The problem seems to be that the PostFile is doing a GET request not a POST. Has something changed?
Thanks

B4A device code -
   
    Dim j As HttpJob
    j.Initialize("fd", "AudioRecord")
           
    Dim urlstr As String =$"${Main.MyWeb}/qldau?type=file&name=${mFileName}"$
    Log($"Send URL =  ${urlstr}"$)
    j.PostFile(urlstr,"/storage/emulated/0/Download/", mFileName)
    Wait For (j) JobDone(j As HttpJob)
    If j.Success Then
        Log("result success ")
        Main.GV.Put("okreply","OK")
        CallSubDelayed(Main,"audio_sent")
    End If
    j.Release
    Stopped = True

B4J - server code
    Sub Handle(req As ServletRequest, resp As ServletResponse)
    Main.filesFolder=File.Combine(File.DirApp, "www/audio")
   
    If req.Method <> "POST" Then
        resp.SendError(500, "method not supported.")
        Return
    End If
    Log(req.Method)

 

[drgottjr]

your urlstr is a get. period. you're mixing a get and a post. technically, not illegal, but, at the same time, there is no spec regarding how a server is expected to respond. you're lucky it worked before; somebody saw it was fishy and called an audible. if you're sending credentials with a file, i suggest posting multipart after cleaning up the url. how you currently handle it was bound to break sooner or later.

 

[labcold]

Thanks for taking time and for your quick reply.
I am confused though and not quite sure how I should proceed.
I followed the tutorial by Erel on this and this is essentially how he did it - although he used POSTBYTES not POSTFILE.
As the server is my own B4J server then I need to add the extras to the url to be sure its the correct action for the servelet to work on - hence the check for POST at the server. I would understand better if this was a generic server.
However I had assumed - maybe wrongly - that calling a library function POSTxxxx would ALWAYS invoke a POST method irrespective of the URL content.
What I had been seeing was that the POSTxxx generated a GET method. Is it that the library function is very generic in its implementation? Otherwise how does one add the extras or hidden elements (as in an HTML submit) to the POSTFILE command as they cannot go into the actual file being sent?
Any help on this would be appreciated.

 

[drgottjr]

i'm going to bow out here. i'm not familiar with the b4j server.

as for okhttputils2, i would urge you to accept that it is well written and not "generic". no offense, but you should focus more on your understanding of exactly what it does and the protocols involved. when you mix a get with a payload (your file), there is no way to guarantee how a given server will handle the request.
if anything, it's an incorrect use of okhttputils2.

to upload a file along with, eg, a file name and, perhaps, other information, you use postmultipart. in effect, this does what you're trying to do, but in a way that the protocol recognizes.

as for how the b4j server handles anything at all, i don't have a clue. it isn't like erel to supply non-compliant stuff, so i would be surprised if it didn't handle postmultipart. i'm not sure i found the tutorial you referred to. the one i saw regarding postbytes seemed to be in a different context. you shouldn't have to use postbytes to send a file (except maybe to send the file as a base64 string). sorry.

 

[Erel]

1. I'm pretty sure that the problem is not related to B4A version.
2. PostFile sends a POST request with the file as the payload. It is not a multipart request.

The first post doesn't describe what exactly happens so I cannot say more.