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.
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.
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 @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.
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.
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.
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.