Üdv!
Kicsit hosszú lesz de eléggé érdekes.
Adott két szerver. Mindkettőn egy soap klienses php script kérdezget egy távoli (harmadik) szervert.
Az egyik soapkliens szervert nem én raktam fel, minden forrásból lett fordítva, nem tudok utánanézni, mi hogy van. Dpkg, phpinfo gyakorlatilag nem mutat semmit, php-soap-ot sem. (!)
A másik szerver sima install, minden csomag apt-gettel jött. Szépen megvan, phpinfoban is látszik hogy OK.
Jelenség: A régi soapkliens szerveren rendben lefut ugyanaz a kód, ami az új soapkliens szerveren nem. A távoli (harmadik szerver) soapserveren el van b*szva a konfig, mert minden egyes kérésre 500-as hibával válaszol. Valami WDSL hiba. De oda nincs loginom. A php fejlesztők arra hivatkoznak, hogy ez az egész eddig működött a régi soapklienses szerverrel és nem tudok erre mit mondani. Fogalmam sincs, hogyan működik egyáltalán.
Ha wgettel kérem le a soapserverről a php URL-t (ami a tartalmat átadná), akkor így néz ki. (A régi és az új soapklienses szerverről is ugyanez!!!!)
# wget [URL]
--2013-01-28 14:13:00-- [URL]
www.domain.hu feloldĂĄsa... 195.70.*.*
CsatlakozĂĄs a kĂśvetkezĹhĂśz: www.domain.hu[195.70.*.*]:80... kapcsolĂłdva.
HTTP kĂŠrĂŠs elkĂźldve, vĂĄrom a vĂĄlaszt... 500 Internal Server Error
2013-01-28 14:13:00 HIBA 500: Internal Server Error.
Tehát ez a hiba a távoli soapserveren keletkezik, aminek a logjaira se látok rá.
Ha az új szerveren nézem a soap klienses php script hibaüzenetét, így néz ki:
Warning: SoapClient::SoapClient([TÁVOLI SZERVEREN AZ URL]) [soapclient.soapclient]: failed to open stream: HTTP request failed! HTTP/1.0 500 Internal Server Error
in /srv/www/htdocs/.... on line 29
Warning: SoapClient::SoapClient() [soapclient.soapclient]: I/O warning : failed to load external entity "[TÁVOLI SZERVEREN AZ URL]" in /srv/www/htdocs/... on line 29
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'TÁVOLI SZERVEREN AZ URL]' in /srv/www/htdocs/.....php:29
Stack trace:
#0 /srv/www/htdocs/.....php(29): SoapClient->SoapClient('http://www.........')
#1 /srv/www/htdocs/.....php(362): require('/srv/www/htdocs...')
#2 /srv/www/htdocs/.....php(321): callPageElements(Array)
[...]
Ha a régi soapklienses szerveren futtatom ugyanezt a php scriptet, ott viszont hiba nélkül végigfut !! és feldolgozza a letöltött XML-t, annak ellenére, hogy az 500-as hibát (wget alapján nézve) ez a szerver is épp ugyanúgy megkapja.
Van valakinek bármiféle ötlete?
- 6196 megtekintés
Hozzászólások
Sejtettem hogy nem lesz túl népszerű a téma. :(
\o\ |o| /o/
- A hozzászóláshoz be kell jelentkezni
"Fatal error: Uncaught SoapFault exception"
try
{
// SOAP hivas
}
catch(Exception $e)
{
var_dump($e);
}
A $e tartalmát bogarászd át, lehet, ott lesz a gond.
Szerk.: Böngészőben megjelenik a WSDL fájl? Az a baj, hogy már nagyon régen írtam (PHP-ban) SOAP server/client-et. Lehet, hogy nem public WSDL, vagy nincs hozzá WSDL fájl. Az URL végéről szedd ki a ?wsdl részt.
-----------
"640GB sokmindenre elég"
- A hozzászóláshoz be kell jelentkezni
Böngészőből nézve a soapserver meghívott php scriptje ezt kimenetet adja:
http://kepfeltoltes.hu/130129/722230658N_vtelen_www.kepfeltoltes.hu_.png
A catch beillesztéséhez bele kéne ásni magam a php kódba, amit nagyon nem szeretnék... De úgy látszik kénytelen leszek a fejlesztők munkáját is magam elvégezni, pff.
\o\ |o| /o/
- A hozzászóláshoz be kell jelentkezni
Miután a SOAP service egy távoli metódushívást valósít meg és ha böngészőben nem adod meg korrektül azt, hogy mit hívsz, akkor nem fog működni.
Az lenne az érdekes, hogy hogyan hívod meg, kódból. (Remélem, nem ilyen fapapucsos módon XML áttúrás megy, mert annál rosszabb nincs, amit el lehet követni SOAP témakörben.)
Másik, hogy konkrétan milyen Exceptiont dob vissza a kód.
Ami még fontos lehet: PHP előszeretettel cacheli be makacsul a WSDL fájlt a tmp könyvtárba, ha változik, figyelni kell rá. Másik, timeout tud még vicces meglepiket okozni, de most fejből meg nem mondom, melyik php.ini változóval függ össze.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
A probléma gyökere szerintem abban rejlik, hogy eltérő verziót használsz a két szerveren.
Erre egy valamiért gyanakszom: 500-as error esetén a soapClient-nek hanyatt kell vágnia magát (az új megteszi, a régi viszont nem, ami bug), gondolom ezt később javították ami neked pont nem jön jól.
- A hozzászóláshoz be kell jelentkezni
phpversion() mit mond a ket szerveren? Szerintem is ott lesz a problema, hogy ket nagyon eltero PHP verziot futtatsz.
Hogy meg sem jelenik a soap kliens a phpinfo-ban, az kulon egy erdekes sztori.
Illetve, a tavoli szerver adminjaval mindenkepp vegyetek fel valamilyen modon a kapcsolatot, hogy ezt a probemat surgosen javitsa. A jovoben sokkal tobbet fogtok ezzel szopni. Az, hogy most mukodik a rendszer, az - ahogy felettem is irjak - BUG.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
A SOAP egy szabványos protokoll, egészen jól megfér egészen különböző rendszerek mellett is. Persze, ha valaki megpróbálja újra feltalálni a kereket (ami rendszerint egy nagyon minimál, trehány implementációban merül ki), akkor jellemzően vannak a viccesebbnél viccesebb hibaüzenetek.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Igen, de azert vannak bizonyos normak, ami mellett eleg nehez elmenni. Peldaul, hogy nem HTTP 500 valaszokban kommunikalunk.
Egyebkent nem teljesen ismeretlen a tema, a cegnel SOAP-pal szivunk, es hat... szoval az ezzel megbizott fejlesztotol meg oszinte mosolyt nem lattam a temaban.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Muhaha, legtöbb szívás azért van, mert valaki gyökér módon használja. Pl. kedvencem, mikor ott a service, de még csak véletlenül sem az szolgálja ki a WSDL-t, hanem odatúrnak hozzám egy valagnyit, hogy nesze, használjam. Meg kilométereken keresztül fejtegetve az XSD fájlok tartalmát (holott az engem totál hidegen hagy), ahelyett, hogy adnának az osztályokról leírást.
Persze a kapott anyagból többnyire nem lehet felépíteni a helyi végpontot, aztán marad a kézzel való tákolás. Na már persze, ha egyáltalán osztályokban gondolkodnak és nem egy egyedi stringet vagy egy XMLDocumentet várnak paraméterül, hogy aztán azt is lehessen külön parseolni.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
Az eredeti szerveren: http://mokolom.aweb.tk/eredeti.htm
Az új szerveren: http://mokolom.aweb.tk/uj.htm
Több nagyon érthetetlen dolog is van itt. A php soapról az eredeti szerveren képtelen vagyok bármi infot begyűjteni, ahogy látszik, nem is lett belefordítva az apache-ba.
A távoli szerver adminja annyira segítőkész, hogy 1 hete kérem tőle az error logokat, hogy legalább azokba belenézzek, de ennyi idő alatt sem érkeztek meg.
Kösz mindenkinek, aki próbál segíteni, de tudom, hogy ez ennyi info alapján szinte lehetetlen. :( Próbálkozok tovább rájönni, miért működik az eredeti szerveren egyáltalán a kód.
A legtöbb, amit észrevettem, hogy más a charset a két szerveren, de ez nem hinném, hogy ilyen különbséget okozhat a soap kliens/szerver kommunikációban.
\o\ |o| /o/
- A hozzászóláshoz be kell jelentkezni
A SOAP a PHP sotohagyereke. Lásd a bugot, amit 2010-ben nyitottunk és felé se bagóztak. Ha tehetitek, cseréljétek le a SOAP libet valami PHP-ban írt megoldásra, az legalább konzisztens lesz.
- A hozzászóláshoz be kell jelentkezni
"soapklienses szerverrel"
Az meg miféle állatfaj? Mert soap kliens meg soap szerver létezik de soapkliens szerver nemigazán.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni
gondolom a szerver amin a soapkliens van
- A hozzászóláshoz be kell jelentkezni
Persze, csak hívjuk már annak, ami...
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
- A hozzászóláshoz be kell jelentkezni