URLCONNECTION - POST

HI everyone.
I’ve been reworking some of my apps with Xojo 19.3.x and moving to URLconnection (noted HTTPSecureSocket is deprecated).
“get” functions seems to work just fine, but “post” do not.
When I “Post” using my legacy HTTPSecureSocket based class everything runs as expected.
When I switch to using URLconnection, with the exact same headers and content, the service I am hitting responds with an altogether different response.
The service I am working with is Shopify.

When using HTTPSecureSocket is call .SetRequestHeader with “User-Agent”, “Authorization” and “Content-Type” headers and then set connectionType to TLSv12
Execute a Post using .SendRequest and all works.

With URLconnection;

WebConnection.RequestHeader(“Authorization”) = "Basic " + EncodeBase64(API + “:” + Password, 0)
WebConnection.AllowCertificateValidation = false
WebConnection.RequestHeader(“Content-Type”) = “application/json”
WebConnection.SetRequestContent(PostSource.Value, “application/json”)
WebConnection.Send(“POST”, PostURLField.value)

Which trigger a total different response.
(various combinations of the above do not work either)

According to what I have read about Shopify (I am paraphrasing here): They implemented a different response for POST requests:

[quote]We made a change that caused POST requests made using basic auth to return the error you are seeing if they the request is passing cookies.
[/quote]
So I can only assume URLconnection is passing a cookie when HTTPSecureSocket is not.

I can’t seem to work out the specific combination of parameters that make URLconnection work with this service. Likewise, there seems to be little control over some of the underlying settings for the class.

Any suggestions? (including; sticking with HTTPsecureSocket at this time).

Thanks

1 Like

Yes, this is true. URLConnection and Xojo.Net.HTTPSocket maintain the cookies for us.

Are you re-using the socket by chance? I would think a new socket should be clear of any cookies.

1 Like

Thanks @Tim Parnell
Not reusing socket. I get the same result running the app from fresh.

I sent the same requests to getsandbox so that I could look at the data that was sent.
The URLconnection POST and the httpsecuresocket headers look the same ! (couple of Accept headers is the only difference I can see.

1 Like

Tried to set the cookie header blank?
WebRequest.RequestHeader(“Cookie”) = “”

1 Like

I see its missing from the test piece of code above but have you tested the URLConnection with a User-Agent set as that isn’t sent through by default and might be a requirement?

1 Like

I haven’t tried this as yet -
WebRequest.RequestHeader(“Cookie”) = “”
But will give it a go tomorrow and report back

I’ve been setting the user-agent for both urlconnection and httpsecuresocket
I will actually try removing it.

Will report back

Thanks

1 Like

@
WebRequest.RequestHeader(“Cookie”) = “”
… this fixed my issue - thank you very much

Perhaps this is something that needs to go into the documentation. It’s odd that I didn’t need to do that with HTTPSecureSocket - but that just makes it a curiosity and not an issue. :slight_smile:

1 Like

Derk suggested the cookie blanking not me, thanks Derk! I’m glad it’s working now. I’m not sure where the cookie comes from, someone would have to do some testing to find out why its not blank to start with before putting in a ticket about this.

1 Like

I think xojo uses a system managed socket type in the background (OS http stuff) xojo just left off the cookie control and other stuff, as with more classes and controls. You are lucky it does work. Shopify should just ignore the given cookie, if the Authorization header is set, that would have been much better.

You can’t actually test the output/input over the httpsocket as you can’t (or you need wireshark) see what’s actually send to the shopify api. Trying in postman or paw won’t show the actual xojo request/response.

1 Like

It’s not that odd. HTTPSecureSocket was written by us as a subclass of SSLSocket, is not up to date and does not include anything like proxy negotiation or cookie handling.

URLConnection is an OS http(s) socket, so you get the benefit and behaviors of whatever the OS provides.

1 Like

Sorry for the incorrect credit @Derk Jochems - thanks for suggestion. Worked.

Shopify specially implemented this (for some reason) just for Post commands - Don’t really understand it - and I know I broke a lot of apps.
Agreed: using Paw and getsandbox was just a quick test to see if anything was obvious in the headers - it’s didn’t really help. Wireshark would have helped.

@Greg O’Lone The point about it being odd is that URLconnection is the recommended replacement for httpsecuresocket but clearly it works differently while not providing the documentation to help developers migrate. If you’ve switched code-base as described;

then you need to explain what the benefits and changes are. You are assuming that I knew that URLConnection provides “the benefit and behaviors of whatever the OS provides” and that this is a significant change compared to the old class.
Your statement in itself is insightful in alerting users to the underlying changes. I am sure you see my point.

Thank you all for helping.

1 Like

FWIW, if you are using Paw, if you set the underlying socket preference to NSURLConnection, you should get identical behavior to our URLConnection class.

1 Like