However when deploying the module to the production-system and using it an exception is thrown containing the following error:

SOAP-ERROR: Parsing WSDL: Couldn't load from 'https://my-webservice-provider/service.wsdl'

This exception was thrown during the initialization of my custom soap client (which derives from SoapClient). So what is the problem here? Two systems worked perfectly. One system is causing troubles. The issue is probably not caused by the code itself…

Conclusion

The error message given by the SoapClient is misleading and should be more precise! The openssl extension for PHP (php5-openssl) simply was not installed on the production system. Because the service is consumed via https openssl is a requirement.

I would asume an error message like: “Cannot load openssl extension” or something like that… But as TDD tells you: Don’t asume anything.

Here comes trouble…

Both environments (production and dev/test-system) connect to the same Oracle database. Inside the production environment all data received from the Oracle database is corrupt due to wrong encoding. A simple mb_detect_encoding shows ‘UTF8′ which cannot be. The whole web-application “is” utf-8. There is no implicit or explicit conversion of encodings performed. So the problem must be caused by the Oracle drivers themselves.

Fixme

setlocale did not work. The encoding option in the dsn (connection string) did not work. What did work was setting the NLS_LANG in the registry. The key can be found inside HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\{SomeInstance}. In this case the NLS_LANG was set to GERMAN_GERMANY.UTF8.

Der Google-Maps-Service ermöglicht Geocoding mittels HTTP-Anfragen. Eine feine Sache und dank JSON als Rückgabeformat und json_decode sehr einfach zu nutzen.

Problem mit dem Encoding und json_decode

Der folgende Code liefert nicht das erwartete Ergebnis. Die Funktion json_decode liefert für die Antwort ein “leeres Ergebnis”.

Eine Analyse von $reponse zeigt einen fehlerhaft codierten String. Das ß ist falsch codiert, obwohl der Reponse in UTF-8 vorliegt (vorliegen sollte).

// Hinweis: Fehlerauswertung fehlt hier gänzlich,
// was in produktivem Code nicht sein darf!
$handle = curl_init ();
$url    = "http://maps.google.de/maps/geo?key=myKey&output=json";
$url   .= "&q=Vollmerhauser Straße 115, 51645 Gummersbach, Deutschland";
 
// Set curl options
curl_setopt ($handle, CURLOPT_URL, $url);
curl_setopt ($handle, CURLOPT_RETURNTRANSFER, 1);
 
// Get code and parse json
$response = curl_exec ($handle);
$json     = json_decode ($response);
 
curl_close ($handle);

Fügt man jedoch einen User-Agent als curl-option (CURLOPT_USERAGENT) hinzu, ist das Ergebnis korrekt und json_decode verrichtet seinen Dienst, wie erwartet. Ein sehr seltsames Verhalten…

// ... Code siehe oben
curl_setopt ($handle, CURLOPT_USERAGENT, 
    'Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050309 Firefox/1.0.1');
// ... Code siehe oben

StatusCode 620 (G_GEO_TOO_MANY_QUERIES)

Der Geocoder liefert eigene Response-Codes (GGeoStatusCode) um den Status der Geocodierung anzuzeigen. Bei vielen Anfragen tritt häufig der Response-Code 620 (G_GEO_TOO_MANY_QUERIES) auf.

Google beschränkt also die Anzahl der Geocoding-Operation pro Sekunde. Deshalb müssen die Anfragen limitiert werden.

// Warte 100ms
usleep (100000);

Nun sinkt natürlich der Datendurchsatz, aber damit kann man leben, denn die Anfragen werden richtig beantwortet.

If you want to “send a file” to the browser (even if you do it in chunks) and your output-buffering is on you will get a fatal error when having large files.

Fatal error: Allowed memory size of 0815 bytes exhausted

It makes sense. The data of the file gets buffered. And after a while the buffer is full.

Always disable your output-buffering before you start sending chunks of data (which represent a file download).

ob_end_clean ();