Android Question [SOLVED] Identical http request - different responses (B4A - B4J)

mc73

Well-Known Member
Licensed User
Longtime User
I'm sending a post request after an initial get, using okHttpUtils2 to a server both by B4A and B4J.
Coding is identical and I'm using the latest versions of both B4A and B4J.
However, the return is different, in fact in B4J I'm getting the expected response url, while in Β4A I get another one (I can see that this means something goes wrong with the redirects).
Attached you may find both examples.
Any help will be greatly appreciated.
 

Attachments

  • b4aTestRequest.zip
    8.5 KB · Views: 163
  • b4jTestRequest.zip
    1.2 KB · Views: 142

Sandman

Expert
Licensed User
Longtime User
I'm curious. This is a brand new site that might show interesting info about the request: https://www.endpoints.dev/

Let endpoints.dev make a unique endpoint for you and use that as server address temporarily. Access with both B4A and B4J and copy the output displayed. It would be interesting to see the difference, so paste in this thread so we all can see?
 
Upvote 0

mc73

Well-Known Member
Licensed User
Longtime User
Make it easier for us to help you. I ran the B4A example and got this in the logs, after modifying your code:

Response url: https://mygovlogin.gsis.gr/oam/server/auth_cred_submit

What is the problem?
Yes, this is the wrong one. If you run it on B4J you'll get Response url: .

It's better to show this with a screenshot from firefox, so that it can be easily seen what should happen with redirects, and in that case B4J works ok.

In B4J, we get to the point of the final login.jsp (that is because I gave wrong username and password but this is not the problem, both versions tested with right credentials too).

In B4A, we return at auth_cred_submit which shows a form telling us that something went wrong with the server. What I do know is that in the middle there is the obrareq.cgi which in B4J is correctly passed, while in B4A, I don't even know if we get there.
 

Attachments

  • getpostredirect.png
    8.3 KB · Views: 151
Upvote 0

mc73

Well-Known Member
Licensed User
Longtime User
In the above post I include a screenshot from firefox, I think it gives much the same info. Thank you!
 
Upvote 0

Sandman

Expert
Licensed User
Longtime User
I think it gives much the same info
Considering that you say that the code in B4A and B4J is identical, and yet they get different results from the server I would say that your screenshot in no way contains the relevant information.
 
Upvote 0

mc73

Well-Known Member
Licensed User
Longtime User
Considering that you say that the code in B4A and B4J is identical, and yet they get different results from the server I would say that your screenshot in no way contains the relevant information.
You are right, this screenshot just demonstrates the correct path, which is not happening in B4A, at least in my setup. Put it another way, in B4J our request is "finalized" correctly, while in B4A it's not for some reason. I would go on showing logs from both mobile and PC, and I would certainly do this if my code was not identical.
 
Upvote 0

mc73

Well-Known Member
Licensed User
Longtime User
The difference is probably related to the server. What is the purpose of the first query?
The first query is performed in order to get some hidden variable which must be used as a post parameter in the second one.

True, they updated the server, installed a new login page and since then this behavior started.

However i'm very curious (apart from the fact that my app stopped working and I really have to either find a solution or return to a webview concept which has low performance), how on earth requests from b4j work great, while in b4a (android perhaps has something to do with it) since I'm sending exactly the same headers and cookies.
 
Upvote 0

Sandman

Expert
Licensed User
Longtime User
Either the requests aren't identical, or the server is differenting between the clients based on their IPs, which doesn't seem very likely.

It would probably be simple to help if you would show us the exact requests from both B4J and B4A, but you don't seem to be interested in doing that.
 
Upvote 0

mc73

Well-Known Member
Licensed User
Longtime User
Ι've already attached the two projects containing the requests, to make things easier to understand. As said, the requests are identical, I'm always copy-pasting things from b4j to b4a in such situations.
 
Upvote 0

Sandman

Expert
Licensed User
Longtime User
As said, the requests are identical, I'm always copy-pasting things from b4j to b4a in such situations.
Just because the code is identical it doesn't mean that the produced request is identical.

Ι've already attached the two projects containing the requests, to make things easier to understand.
Sorry, no. I was willing to help you investigate the resulting requests, but not your code.
 
Upvote 0

OliverA

Expert
Licensed User
Longtime User
It could be that the underlying library, be it the actual 3rd party library or the B4X wrapper around the library, do something different on each platform. If it is the wrapper, then the fix may be doable. If it is the underlying library, the fix may not be trivial. Sources to both (B4J and B4A) are available on Git. In this forum search for “framework open source” and you should find the link to Git repository
 
Upvote 0

mc73

Well-Known Member
Licensed User
Longtime User

Thank you Oliver, this is what I suspect too, however by watching the logs, I can't seem to differentiate something in order to dive deeper into the source.
A perhaps interesting note I did the other day, was that very rarely I get the very same error page (the one I get with B4A) by simply using Firefox on my PC. No difference was found in the request data. This means that Erel is of course right, there is something going on with the server, still, it's another thing that an error comes occasionally, and another one when it's the rule. I'm getting very curious
 
Upvote 0

OliverA

Expert
Licensed User
Longtime User
When you create an http request, the client and server do negotiate some connection parameters. Maybe something goes afoul during that face. You would have to use something like Wireshark and look at the whole negotiation process. Problem is that the site is https (actually, that is good, just not for diagnosing with wireshark). You could also use this site ( https://ptsv2.com/) to see what headers each browser / B4X client sends to see if you spot something
 
Upvote 0

mc73

Well-Known Member
Licensed User
Longtime User
I actually did that on the site you posted , and sandman's proposed one. Identical headers. There has to be something deeper unfortunately.
 
Upvote 0

mc73

Well-Known Member
Licensed User
Longtime User
It is the exact same implementation in B4A and B4J, still there could be other differences that depends on the OS / Java features such as support for Http/2 and TLS protocols.

The correct way to debug it is with wireshark.
Sure. A question about the different os attitude. Could it be that somehow one repeats the request upon a failure? Anyone noticed such behavior?
 
Upvote 0
Cookies are required to use this site. You must accept them to continue using the site. Learn more…