Google API session token aanvragen geeft 502 Bad Gateway

[maurad3r]

Tweakers,

Ik ben bezig om gebruikers van mijn website die Picasa hebben de mogelijkheid te geven om die fotos te tonen. Hiervoor moeten gebruiks toestemming geven: dit gaat normaal door eerst een token aan te vragen, en vervolgens deze token in te wisselen voor een session token.

In deze laatste stap krijg ik echter een "502 Bad Gateway" (nginx/0.5.35) fout! Het vreemde is dat dezelfde code op andere servers waar ik test geen problemen geeft. Het gaat hoogstwaarschijnlijk dus om een configuratiefout op de server. Ik heb jammergenoeg geen idee wat er fout gaat, en ook op Google kan ik geen antwoorden vinden.

De (relevante) PHP code die ik gebruik om dit te testen is sterk afgeleid van de voorbeeld code die op de documentatie pagina te zien is en makat gebruik van het Zend Framework.

PHP:

$session = new Zend_Session_Namespace('picasa');
if( !isset($session->sessionToken) )
{
    if( isset($_GET['token']) )
    {
        $client = NULL;
        // Hier geef ik eventueel een andere manier van verbinden op
        //$client = Zend_Gdata_AuthSub::getHttpClient($_GET['token']);
        //$client->setAdapter(new Zend_Http_Client_Adapter_Socket());
        
        // De onderstaande aanroep zal een 502 Bad Gateway (nginx/0.5.35) error opleveren,
        // ongeacht van welke methode van verbinden ik gebruik (socket, proxy, curl)
        $session->sessionToken = Zend_Gdata_AuthSub::getAuthSubSessionToken( $_GET['token'], $client );             
    }
    else
    {
        $nextUrl = 'http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
        $scope = 'http://picasaweb.google.com/data';
        $secure = 0;
        $session = 1;
        $authSubUrl = Zend_Gdata_AuthSub::getAuthSubTokenUri($nextUrl, $scope, $secure, $session);                    
        
        header('location: ' . $authSubUrl);
        exit;
    }
}

if( isset($session->sessionToken) )
{
    // Tot dit punt komt het script dus nooit
    $client = Zend_Gdata_AuthSub::getHttpClient($session->sessionToken);
}

Iemand enig idee wat er mis kan gaan/gaat?

Bedankt!

[CoolGamer]

Het lijkt erop dat de request via een proxy server (nginx) loopt, die niet goed is afgesteld. Lijkt me een serverconfiguratie. (Maar dat zou natuurlijk ook aan Google's kant kunnen zitten.)

[ Voor 20% gewijzigd door CoolGamer op 02-01-2010 19:54 ]

[djluc]

Dit komen wij ook regelmatig tegen en we zien geen mogelijkheid waar dat aan kan liggen!

[maurad3r]

Aangezien Google zo groot is en ik nergens anders dit probleem is ga ik er maar vanuit dat het niet Google is die problemen veroorzaakt.

Ik heb jammergenoeg te weinig ervaring met nginx om echt te weten wat ik moet aanpassen. Wat zijn instellingen die mogelijk verkeerd zouden kunnen staan of iets zouden kunnen veranderen?

djluc schreef op zaterdag 02 januari 2010 @ 19:44:
Dit komen wij ook regelmatig tegen en we zien geen mogelijkheid waar dat aan kan liggen!

Maar wat is jullie oplossing dan geweest? Ik zie ook niet écht workarounds om rond het probleem heen te werken.

[djluc]

Tot op heden geen oplossing gevonden behalve caching. Dus als de api niet draait tonen we de laatste resultaten welke we nog hebben. Kwestie van goede error afhandeling dus, de api voorziet daar wel goed in.

[Erik Jan]

Als die server alleen maar via een proxy op internet mag, moet jouw HTTP client dat wel weten. Hier onder het kopje "Requests are timing out when using the client library" staat hoe. Staat het apparaat heel toevallig in een kantoornetwerk?

Anders kan het inderdaad aan andere omgevingszaken op de server liggen als locale, versies, firewalls e.d.

[ Voor 7% gewijzigd door Erik Jan op 03-01-2010 15:49 ]

[djluc]

Die melding kregen wij totaal @random en werd ook weer opgelost zonder enig ingrijpen van ons dus ik denk echt dat het bij de API servers ligt.

[maurad3r]

Een groot verschil is wel dat deze "502 Bad Gateway" bij ons altijd voorkomt (al moet ik toegeven dat er tijden zijn geweest dat het nog wel eens ooit lukte, maar dat is al een paar weken niet meer het geval). Er is dus helemaal niet met de API te werken.

Het lijkt ook niet om een time-out te gaan, de server geeft deze 502 error meteen terug, het lijkt niet dat er sprake is van enige time-out (ook als ik de timeout op bv 20 zet). De server staat verder gewoon in een goed datacentrum.

Erik Jan schreef op zondag 03 januari 2010 @ 15:47:
Als die server alleen maar via een proxy op internet mag, moet jouw HTTP client dat wel weten.

Ik geloof niet dat dit het geval is, maar hoe zou ik dit kunnen controleren?

Alvast bedankt!

[Erik Jan]

Nou als het ding gewoon bij een ISP staat is die kans klein. In een bedrijfsnetwerk / intranet echter weer wat groter. Vraag het bij wie de server beheert, of test het zelf met SSH (met wget) of remote desktop (in IE, options->connections->LANsettings o.i.d.). Let op dat de request ook over HTTPS kan lopen.

Maar dit geldt alleen als het probleem zich _op dit moment_ op server X niet voordoet en op server Y wel, met identieke code. Anders kan het best iets in de code zijn of met de Google service zoals bij djluc.

[djluc]

Wij hebben het uitgebreid getest en zijn echt tot die conclusie gekomen. Het verhaal van de proxies e.d. was me nog niet bekend maar dat het hier iets mee te maken heeft zou goed kunnen: (nginx/0.5.35). Anders heeft het sowieso een andere error aangezien ze voor vrijwel alles errors afvangen. Denk aan overloads door teveel requests etc.

[maurad3r]

Ik ben weer wat verder met zoeken naar het probleem. Ik krijg in Apache een '[notice] child pid 29130 exit signal Segmentation fault (11)'. Dit is volgens mij over het algemeen een melding van een functie die illegaal aangeroepen wordt (hiermee bedoel ik niet dat de code verkeerd is) maar dat wellicht 1 van de onderdelen een illegale bewerking uitvoert of in de clinch ligt met een ander geinstalleerd onderdeel.

We hebben ondertussen ook al getest zonder nginx en ook nog zonder het gebruik van eAccelerator. In beide gevallen blijfven er problemen. Ook lijken er alleen problemen te zijn als er verbonden moet worden met een https server.

Ik heb een backtrace gestart, met het onderstaande resultaat. Jammergenoeg kan ik daar niet zo veel mee! Jullie enig idee wat de oorzaak kan zijn?

code:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1094719840 (LWP 29695)]
0x00000030869697f5 in free () from /lib64/tls/libc.so.6
(gdb) bt
#0  0x00000030869697f5 in free () from /lib64/tls/libc.so.6
#1  0x000000308864d8f9 in CRYPTO_free () from /lib64/libcrypto.so.4
#2  0x00000030886b3997 in ASN1_STRING_free () from /lib64/libcrypto.so.4
#3  0x00000030886ad92f in ASN1_primitive_free () from /lib64/libcrypto.so.4
#4  0x00000030886adce7 in ASN1_template_free () from /lib64/libcrypto.so.4
#5  0x00000030886adc01 in ASN1_primitive_free () from /lib64/libcrypto.so.4
#6  0x00000030886add22 in ASN1_item_free () from /lib64/libcrypto.so.4
#7  0x0000003088696543 in sk_pop_free () from /lib64/libcrypto.so.4
#8  0x000000308842375f in ssl_sess_cert_free () from /lib64/libssl.so.4
#9  0x000000308842429f in SSL_SESSION_free () from /lib64/libssl.so.4
#10 0x0000003088422519 in SSL_free () from /lib64/libssl.so.4
#11 0x0000002a967553ff in Curl_SSL_Close () from /usr/lib64/libcurl.so.3
#12 0x0000002a9674e6fd in Curl_disconnect () from /usr/lib64/libcurl.so.3
#13 0x0000002a967509a0 in Curl_done () from /usr/lib64/libcurl.so.3
#14 0x0000002a9675cf3d in Curl_perform () from /usr/lib64/libcurl.so.3
#15 0x0000002a95b249dc in zif_curl_exec (ht=Variable "ht" is not available.
) at /usr/local/php-5.2.1/ext/curl/interface.c:1673
#16 0x0000002a95d7c766 in zend_do_fcall_common_helper_SPEC (execute_data=0x413f7b40, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:200
#17 0x0000002a95d7bc96 in execute (op_array=0x2a9cf316e0, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:92
#18 0x0000002a95d7bfa9 in zend_do_fcall_common_helper_SPEC (execute_data=0x413f9390, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:234
#19 0x0000002a95d7bc96 in execute (op_array=0x2a9cf2d658, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:92
#20 0x0000002a95d7bfa9 in zend_do_fcall_common_helper_SPEC (execute_data=0x413f9e90, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:234
#21 0x0000002a95d7bc96 in execute (op_array=0x2a9cf10d90, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:92
#22 0x0000002a95d7bfa9 in zend_do_fcall_common_helper_SPEC (execute_data=0x413fa7c0, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:234
#23 0x0000002a95d7bc96 in execute (op_array=0x2a9cee86e0, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:92
#24 0x0000002a95d7bfa9 in zend_do_fcall_common_helper_SPEC (execute_data=0x413faeb0, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:234
#25 0x0000002a95d7bc96 in execute (op_array=0x2a9cef28b8, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:92
#26 0x0000002a95d7bfa9 in zend_do_fcall_common_helper_SPEC (execute_data=0x413fbdb0, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:234
#27 0x0000002a95d7bc96 in execute (op_array=0x2a9cd9a2a0, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:92
#28 0x0000002a95d7bfa9 in zend_do_fcall_common_helper_SPEC (execute_data=0x413fd870, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:234
#29 0x0000002a95d7bc96 in execute (op_array=0x2a9cd686e0, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:92
#30 0x0000002a95d7bfa9 in zend_do_fcall_common_helper_SPEC (execute_data=0x413fdd10, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:234
#31 0x0000002a95d7bc96 in execute (op_array=0x2a9cd733d8, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:92
#32 0x0000002a95d7bfa9 in zend_do_fcall_common_helper_SPEC (execute_data=0x413fdf90, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:234
#33 0x0000002a95d7bc96 in execute (op_array=0x2a9cce9f68, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:92
#34 0x0000002a95d7bfa9 in zend_do_fcall_common_helper_SPEC (execute_data=0x413fe930, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:234
#35 0x0000002a95d7bc96 in execute (op_array=0x2a9cce7388, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/Zend/zend_vm_execute.h:92
#36 0x0000002a95d5a689 in zend_execute_scripts (type=8, tsrm_ls=0x2be53b0, retval=Variable "retval" is not available.
) at /usr/local/php-5.2.1/Zend/zend.c:1135
#37 0x0000002a95d10799 in php_execute_script (primary_file=0x41400e20, tsrm_ls=0x2be53b0) at /usr/local/php-5.2.1/main/main.c:1784
#38 0x0000002a95ddd94b in php_handler (r=0x8ad048) at /usr/local/php-5.2.1/sapi/apache2handler/sapi_apache2.c:623
#39 0x0000000000433403 in ap_run_handler (r=0x8ad048) at config.c:157
#40 0x00000000004338a1 in ap_invoke_handler (r=0x8ad048) at config.c:372
#41 0x0000000000449e9f in ap_internal_redirect (new_uri=Variable "new_uri" is not available.
) at http_request.c:477
#42 0x0000002a958cca73 in handler_redirect (r=0x8b7448) at mod_rewrite.c:4733
#43 0x0000000000433403 in ap_run_handler (r=0x8b7448) at config.c:157
#44 0x00000000004338a1 in ap_invoke_handler (r=0x8b7448) at config.c:372
#45 0x000000000044a2d0 in ap_process_request (r=0x8b7448) at http_request.c:258
#46 0x0000000000447cbd in ap_process_http_connection (c=0x8a8600) at http_core.c:184
#47 0x0000000000439cd3 in ap_run_process_connection (c=0x8a8600) at connection.c:43
#48 0x000000000045cd13 in worker_thread (thd=0x617cc8, dummy=Variable "dummy" is not available.
) at worker.c:544
#49 0x0000003087c06137 in start_thread () from /lib64/tls/libpthread.so.0
#50 0x00000030869c9f03 in clone () from /lib64/tls/libc.so.6

[maurad3r]

Een klein kickje van dit topic! Ik hoop dat er iemand is die me met bovenstaande informatie in de goede richting kan duwen. Ik heb er zelf nog flink wat tijd ingestopt, maar ik kom gewoon niet verder. Mocht er informatie ontbreken, of iets niet duidelijk zijn hoor ik het ook graag.

[hostname]

Lijkt op een bug in PHP. Misschien PHP eens updaten naar 5.2.12. Zie in de changelog namelijk wel wat bugfixes m.b.t tot CURL en segfaults.

[maurad3r]

We hebben al een keer een PHP-update gedaan (naar de toen recenste versie), dat heeft geen enkel effect gehad jammergenoeg! Ik geloof dat we nog altijd de meest recente versie draaien, maar dat moet ik even nakijken.

[hostname]

maurad3r schreef op donderdag 07 januari 2010 @ 21:31:
We hebben al een keer een PHP-update gedaan (naar de toen recenste versie), dat heeft geen enkel effect gehad jammergenoeg! Ik geloof dat we nog altijd de meest recente versie draaien, maar dat moet ik even nakijken.

In je backtrace staat /usr/local/php-5.2.1/Zend/zend.c, en 5.2.1 is al meer dan 2 jaar oud.

[maurad3r]

We hebben de update recent uigevoerd en die gaf eenzelfde trace. Maar ik zal proberen morgen een nieuwe te leveren die met behulp van die php versie is gemaakt! Wellicht toch kleine (relevante) verschillen.

[ Voor 12% gewijzigd door maurad3r op 08-01-2010 00:27 ]

[maurad3r]

We hebben het probleem even links laten liggen omdat we er maar niet uitkwamen, maar we zijn nu weer op het punt dat we er actief werk van gaan maken. De afgelopen week weer een hoop dingen geprobeerd maar nog steeds geen resultaat.

We hebben inmiddels nieuwste PHP draaien, en ik heb ook weer een nieuwe stacktrace gemaakt met die PHP versie. Deze staat hieronder:

code:

#0  0x00000030869697f5 in free () from /lib64/tls/libc.so.6
#1  0x000000308864d8f9 in CRYPTO_free () from /lib64/libcrypto.so.4
#2  0x00000030886b3997 in ASN1_STRING_free () from /lib64/libcrypto.so.4
#3  0x00000030886ad92f in ASN1_primitive_free () from /lib64/libcrypto.so.4
#4  0x00000030886adce7 in ASN1_template_free () from /lib64/libcrypto.so.4
#5  0x00000030886adc01 in ASN1_primitive_free () from /lib64/libcrypto.so.4
#6  0x00000030886add22 in ASN1_item_free () from /lib64/libcrypto.so.4
#7  0x0000003088696543 in sk_pop_free () from /lib64/libcrypto.so.4
#8  0x000000308842375f in ssl_sess_cert_free () from /lib64/libssl.so.4
#9  0x000000308842429f in SSL_SESSION_free () from /lib64/libssl.so.4
#10 0x0000003088422519 in SSL_free () from /lib64/libssl.so.4
#11 0x000000317251b3ff in Curl_SSL_Close () from /usr/lib64/libcurl.so.3
#12 0x00000031725146fd in Curl_disconnect () from /usr/lib64/libcurl.so.3
#13 0x00000031725169a0 in Curl_done () from /usr/lib64/libcurl.so.3
#14 0x0000003172522f3d in Curl_perform () from /usr/lib64/libcurl.so.3
#15 0x0000002a95b4aa00 in zif_curl_exec (ht=Variable "ht" is not available.
)
    at /usr/local/php-5.2.12/ext/curl/interface.c:1849
#16 0x0000002a95d8e236 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x5d624930, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:200
#17 0x0000002a95d8d766 in execute (op_array=0x2a9d190058, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:92
#18 0x0000002a95d8da79 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x5d626180, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:234
#19 0x0000002a95d8d766 in execute (op_array=0x2a9d16a3b0, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:92
#20 0x0000002a95d8da79 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x5d626c80, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:234
#21 0x0000002a95d8d766 in execute (op_array=0x2a9d10be00, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:92
#22 0x0000002a95d8da79 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x5d6275b0, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:234
#23 0x0000002a95d8d766 in execute (op_array=0x2a9c09fce0, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:92
#24 0x0000002a95d8da79 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x5d627ca0, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:234
#25 0x0000002a95d8d766 in execute (op_array=0x2a9c0cbfe8, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:92
#26 0x0000002a95d8da79 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x5d628ba0, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:234
#27 0x0000002a95d8d766 in execute (op_array=0x2a9c30dd18, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:92
#28 0x0000002a95d8da79 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x5d62a660, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:234
#29 0x0000002a95d8d766 in execute (op_array=0x2a9c301348, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:92
#30 0x0000002a95d8da79 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x5d62ab00, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:234
#31 0x0000002a95d8d766 in execute (op_array=0x2a9c082f10, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:92
#32 0x0000002a95d8da79 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x5d62ad80, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:234
#33 0x0000002a95d8d766 in execute (op_array=0x2a9a5f2ac8, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:92
#34 0x0000002a95d8da79 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x5d62b8d0, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:234
#35 0x0000002a95d8d766 in execute (op_array=0x2a9a5db3d0, tsrm_ls=0xa6de40)
    at /usr/local/php-5.2.12/Zend/zend_vm_execute.h:92
#36 0x0000002a95d6b769 in zend_execute_scripts (type=8, tsrm_ls=0xa6de40,
    retval=Variable "retval" is not available.
) at /usr/local/php-5.2.12/Zend/zend.c:1134
#37 0x0000002a95d205e9 in php_execute_script (primary_file=0x5d62ddc0,
    tsrm_ls=0xa6de40) at /usr/local/php-5.2.12/main/main.c:2036
#38 0x0000002a95df1efb in php_handler (r=0x2a9a2065e0)
    at /usr/local/php-5.2.12/sapi/apache2handler/sapi_apache2.c:637
#39 0x0000000000436103 in ap_run_handler (r=0x2a9a2065e0) at config.c:157
#40 0x00000000004365a1 in ap_invoke_handler (r=0x2a9a2065e0) at config.c:372
#41 0x000000000044d92f in ap_internal_redirect (new_uri=Variable "new_uri" is not available.
) at http_request.c:501
#42 0x0000002a958d7e03 in handler_redirect (r=0x9cbc08) at mod_rewrite.c:4819
#43 0x0000000000436103 in ap_run_handler (r=0x9cbc08) at config.c:157
#44 0x00000000004365a1 in ap_invoke_handler (r=0x9cbc08) at config.c:372
#45 0x000000000044ddc0 in ap_process_request (r=0x9cbc08) at http_request.c:282
#46 0x000000000044b4dd in ap_process_http_connection (c=0x977aa0)
    at http_core.c:190
#47 0x000000000043cbc3 in ap_run_process_connection (c=0x977aa0)
    at connection.c:43
#48 0x0000000000461293 in worker_thread (thd=0x61e568, dummy=Variable "dummy" is not available.
) at worker.c:544
#49 0x0000003087c06137 in start_thread () from /lib64/tls/libpthread.so.0
#50 0x00000030869c9f03 in clone () from /lib64/tls/libc.so.6

Het enige wat mij hier aan opvalt is dat er vaak iets staat als "variable not avaidable" (als in "Variable "ht" is not available", "retval=Variable "retval" is not available", "dummy=Variable "dummy" is not available"). Maar hierop Googlen geeft geen zinnige resultaten jammergenoeg.

Iemand enig idee? Of welke richting ik in moet zoeken?

[igmar]

Verander je Apache MPM van worker / event naar prefork en het probleem is naar alle waarschijnlijkheid verholpen.

[maurad3r]

Dat maakte helaas ook geen verschil Igmar. Toch bedankt voor de hulp.

Gelukkig is het inmiddels wél opgelost! En ik wilde graag nog even aangeven wat het precies is geweest voor de ongelukkige die hier ook mee te maken gaan krijgen ;):

Bij een controle na het omschakelen naar de prefork merkte we op dat https niet als registered stream in PHP stond. Na dat aangepast te hebben werkte het opeens.

Bedankt voor de hulp!