I have a very strange problem and hope someone has some idea how I can fix it…
I have an iOS app that uses a xojo.Net.HTTPSocket to send some data to a PHP script that is running on my company’s web server (hosted by Register.com)…
As expected the socket’s PageReceived event fires and I get a 200 HTTP response code… but instead of the expected “contents” I get “The requested URL was rejected. If you do not think this an error please contact the webmaster…” and the php code never actually executes.
So I am thinking that the ISP is blocking my request… but if I type that same URL into a browser the php code executes and I get the correct expected result.
I see the exact same problem with my app running on my iOS device, and debugging with the simulator. I also built a desktop app that uses a classic HTTP socket and have the same problem.
I have googled that error message and it seems my problem is not unique… but most of the problems were solved by clearing browser cookies… which does not seem to me to bee the issue here.
This was all working just fine until about a month ago.
The server log does not show anything… even a rejection… I do see a record when I hit the URL with Safari but nothing with me app.
I will try https but I have some other php scripts that are running from a “http post” from my Vera Edge (z-wave home automation hub) and those urls are simple http… I see those in the server’s log.
I guess I am going to have to contact my ISP… but I am not sure what help they will be since I can access the script with Safari and my Vera Edge… It only fails under my Xojo code.
well that certainly changes the problem
I didn’t read the entire thread and just saw gregs response which was referring to iOS urls (which do need to be https)
your isp might be able to tell you why this difference as I cant think of one off the top of my head
seems very odd
If the server log doesn’t show anything and you got a 200 response it’s possible that the server script returned the error you see. Have you searched the php code for that particular error message?
As for contacting your ISP, ISPs don’t handle this sort of thing. This is almost certainly a software issue. Unless you’re referring to your hosting provider as your ISP, in which case they may be able to help.
The way I would figure this out is to capture the traffic and see what is actually happening. Unfortunately it’s not as easy with https as it is with http, but it can be done. You can proxy the traffic through software that will capture the request and response, or you can use Wireshark and set it up so it can decrypt the connection. I haven’t needed to do this in a while, but I’m sure you can google it to find out how it works. I think you have to provide it with your cert and key somehow. If you don’t have that then it is probably easier to use a man in the middle proxy arrangement.
Once you have this set up you should be able to see very quickly what the differences are and whether or not it is actually the server that is returning that response to you. If it is then you will need to look at the server code to find out what the potential solutions might be.
OK… some progress… Greg put me on the right track… Using the xojo.Net.HTTPSocket in the desktop app does now connect/communicate with the php script… But if I try to include any content in my post using something like:
It also turns out that if I do not set the RequestContent (i.e. leave it empty) in my original iOS app, it also does communicate properly with the PHP script… but I need to send some data.
Kevin… yes, I was incorrect in saying “ISP” when I meant to say “host provider”… but my php script is only about 10 lines long and there is no way it is returning that error…
I guess anything is possible… especially if the host provider changed the PHP version or some of the php.ini settings… I am currently checking with them. It was working fine for months… then just stopped.
The php code itself is very simple… it just takes the content of the post and saves it as a file… But since the post is never even recorded in the server log my guess is that it is not the script.
In a standard HTTP POST request, the multipart/form-data header must include the boundary string, otherwise there’s no way for the server to parse the form data.
I have to admit that I really did not think that was the issue… mainly because this code had worked for several months… But changing the mime-type to “text/plain” fixed the problem.
My guess is that you aren’t actually sending a multipart-encoded HTTP form but rather some other kind of data, and that previously the server was ignoring the fact that the mime type was wrong.
It is certainly possible that the host company changed their server software… possibly just the version, some security or other settings… I contacted them but was told that my contract was a DIY and did not include support… so they could not answer my questions… (I will be moving to another host at the next opportunity.)