It’s not really a Xojo thing, it’s just the way the web works. If you need to make a POST, you do it from either a <form> element with method set to POST, or you make a background request with fetch/XmlHttpRequest/your tool’s equivalent. In Xojo, that is URLConnection. Only the <form> tag will tell the browser to navigate to a page, the others return the raw data for processing in code.
So if URLConnection won’t do what you need, neither will XmlHttpRequest. I’m just trying to save you some time if you’re looking to reimplement this in something else.
When we handle URL, we can also redirect depending on path or parameters. The incoming request, to be redirected, may carry a QueryString and/or Body. We can agree on that. It is usual situation to carry Query String for redirecting, and Body for responding. But, since query is viewable in browser, I do have security concerns. Now, I can submit a form (to simulate), but the form is eventually - just a hiden Query String (which is solid way). However, I want Body to be a JSON. That was the idea of the question. Unfortunately we are not closer to answer from the conversation begining. My customers are actually doing that. They DO send JSON as body, rather than a query string. I wanted to simulate that. Can’t be done in Xojo - it is all ok. But, most definately, I can be done, since I am actually redirecting requests with Body.
Well… you’re wrong about some aspect of this. Xojo can send JSON in the body of a POST request using URLConnection. It’s a piece of cake and I do it all the time. But no browser is going to do so.
You may also have some fundamental misunderstandings about what HTTP is doing. You mention the query string being less secure, but… it’s no different than a POST. Yes, the query string is visible in the url. But that happens after the TLS connection is made. So the difference between POST and GET is obscurity, not security.
Here’s my final plea before I drop out of this conversation, because it’s going nowhere. You need to rethink your approach. I’ve been doing this a long time, I know all about how the web works. I’ve written an HTTP server in Xojo, wrote the original Web Edition for Xojo, much of the IDE, and I have the second most starred Xojo project on GitHub.
If you want some non-Xojo answers, check out json - POST: sending a post request in a url itself - Stack Overflow. Every single answer says what I’m telling you: it cannot be done. You can make requests with curl, jquery, postman, xmlhttprequest, urlconnection, rapidapi… there are tons of options for making custom requests. But you cannot get the browser to do it as part of navigation. It’s not something Xojo is lacking, it just cannot be done.
Thank you for clarifying some points of your goal.
Unfortunately this is a very old question to a problem that has long since been solved by the evolution of the HTTP protocol. We may not like the constraints of HTTP, but those constraints are there for everyone’s protection (customer & vendor). And every application, operating system and device between your customer and your website is going to force you to comply with those constraints - so why reinvent the wheel?
As @Thom_McGrath, @Tim_Parnell and others have tried to point out, this is not a limitation of Xojo, but a constraint imposed by HTTP.
Unless I’ve missed it, you haven’t explicitly said whether you’re building a Desktop app to talk to your website, or if it is two websites talking to each other, or you just have a single website.
If I assume Desktop-to-Web. Then you need to build in a Web API for your website to capture whatever kind of custom POST “body” content (json, xml, etc.) and headers you send using URLConnection. This is a proven secure approach to the problem as long as your website is SSL compliant (i.e., using HTTPS).
If Website-to-Website, you’re going to have challenges getting your customer’s browser to allow cross-site posting. But HTTP does allow for it, with additional effort on your part to notify the posting site that such posts are “safe” to send.
If a single website, then you have numerous options available to you as other’s have pointed out here. Either through the use of JavaScript or Xojo Web.
In all cases, ensure your website is using HTTPS. Adding a VPN, as suggested, would pretty much guarantee you an extra layer of uber-security beyond just HTTPS (which is good enough for my online banking).
This part of your goal is a bit vague and the term “pre-agreed” is a possible cause of concern. If visitors don’t have control over their own passwords, that could back-fire on you in ways you won’t expect.
Regardless, with whatever solution you dream up, it is in your best interest to implement the session-cookie model for managing authenticated connections to your website.
You’ve gotten a lot of valuable advice here from folks that have spent years working within the constraints of the HTTP protocol, please listen to them.
A 307 will redirect the client request to a different target. A 307 will not cause the client to modify the request any more than is necessary. A 307 will not cause the target to accept session data associated with the original location.
Query strings are a feature of the CGI that sits beside the HTTP layer. Headers are within the HTTP layer. Browsers such as Chrome, Firefox, Safari make HTTP requests and handle HTTP responses according to agreed standards, which do not permit the layers above HTTP to tamper with the HTTP layer itself. To manipulate headers you need write access to the HTTP layer which is what URLConnection is for.
If a 307 has solved your problem it seems your problem was misunderstood. To be honest I am really struggling to follow your use case. HTTP is a simple, stateless, protocol. Requests are sent From a Client To a Server that replies with a Response. It helps to describe problems and solution in those terms.
Yeah there’s definitely a misunderstanding somewhere. A 307 would instruct the browser to remake the request to the new url, but I can’t see how that helps. If you can make a POST to the first url, you can make it to the other url without the middleman.