2

I understand this has been asked before but perhaps not in the context I am using.

Our dialling system has a method of inputting form based leads into their dialler. You have to visit a certain website, for example:

http://www.website.com/non_agent_api?source=webform&telephone_number=0123456789&name=Bloggs

I am currently using

file_get_contents('http://www.website.com/non_agent_api?source=webform&
telephone_number=0123456789&name=Bloggs')

But it appears to be quite hit and miss Id say about only 70% of the leads get added correctly.

Does anyone know of an alternative?

JayC
  • 7,053
  • 2
  • 25
  • 41
user3178795
  • 39
  • 1
  • 4
  • 4
    You could try to use curl. It has a few more options. I just showed some examples in another answer: http://stackoverflow.com/questions/20924100/best-way-to-parse-multiple-plain-text-websites-that-contain-no-html/20925220#20925220 – Floris Jan 09 '14 at 18:05
  • Scroll all the way to the bottom of my linked answer and look at the `myCurl` function I defined there. Might make a starting point... – Floris Jan 09 '14 at 18:07
  • Do you have any idea on how the "add lead" fails? Could it be that the number is malformed, there are spaces or other "forbidden" characters in the name, etc? I doubt that `file_get_contents()` is actually your problem. This might be a case of [the X-Y problem](http://www.perlmonks.org/?node_id=542341)? – Floris Jan 09 '14 at 18:10
  • I got cURL to work.. but yes Floris, you may be correct. – user3178795 Jan 09 '14 at 18:13
  • There is absolutely no reason why something else should work where `file_get_contents()` fails. This could be down to a shaky connection, intermittent server failures... that `file_get_contents()` is the culprit is actually extremely unlikely. – Pekka Jan 09 '14 at 18:14
  • generally with the phone number all spaces are removed. – user3178795 Jan 09 '14 at 18:15
  • i think i will contact support to see if there are any forbidden characters! – user3178795 Jan 09 '14 at 18:15
  • 1
    You could/should log and analyze errors - both on the script's end and on the remote server's end if you have control over it. Chances are the failing requests are causing an error somewhere. – Pekka Jan 09 '14 at 18:16
  • Characters are "forbidden" in the URL request - this has nothing to do with the specific application, but just with the rules of the internet - you MUST urlencode the name for sure!!! There may be additional problms at the server / application end, but clearly you must make sure you have a well-formed request. – Floris Jan 09 '14 at 18:20
  • thanks Floris, you've got me to check my validation and I believe the problem lays there! – user3178795 Jan 09 '14 at 18:27
  • Glad to hear my comments were helpful. I have consolidated some of them into an answer. If the problem is indeed addressed by this, you might want to answer it as "solved" (by accepting the answer). – Floris Jan 09 '14 at 19:56

1 Answers1

0

It is unlikely that a failure of file_get_contents is the root cause of your problem. It is more likely that you are creating an ill-formed request - for example, that you are not properly URLencoding the parameters. Do you have a method for validating the inputs before generating the request? Do you use proper encoding? Are you aware of any validation rules at the server end that may make your requests fail?

You can try to use cURL as an alternative to file_get_contents - that is the answer to the question you asked. But more likely the actual problem lies in the proper encoding / validation of your request.

Exmaple:

$name = "Freddy Mercury";
$e_name = urlencode($name);
$request = "http://www.server.com/addEntry.php?name=".$e_name;
echo $request

Results in

http://www.server.com/addEntry.php?name=Freddy+Mercury

As you can see, the 'forbidden' space is replaced with the + sign. You might want to include other validation functions before generating your request.

Floris
  • 45,857
  • 6
  • 70
  • 122