ugrás a tartalomhoz

Linux+Apache+PHP: XML válasz elromlik - miért?

tisch.david · 2011. Május. 13. (P), 16.09
Sziasztok!

Van egy PHP scriptem, ami egy webszolgáltatást hív meg fopen()-nel, és a válasz XML-t adja vissza. Ha ezt a kódot a gépemen futtatom, WAMP alatt, akkor megy remkül, ha viszont felteszem az egyik linuxos szerverünkre, akkor a válasz XML-ben a node-ok (a windows-os camel case helyett) csupa kisbetűsek lesznek, és bizonyos XML node attribútumok (pl. nil=1) invalid módon kerülnek a dokumentumba (pl. így, " nélkül).

Mi okozhatja ezt?

Előre is köszönöm a válaszokat!
Üdv:

Dávid
‹ CodeIgniter, MVC, OOP - elméleti kérdés hogy hogyan is épüljön fel az oldal Egyedi panel (törlésre jelölve) ›
 ■
1

Hol?

Poetro · 2011. Május. 13. (P), 16.17
Hol lesz más az XML? Mást tölt le? Más lesz a fájl tartalma? Vagy az XML értelmező kód értelemezi másképp az XML-t. Tudsz mutatni egy minimális példát, amivel reprodukálható a probléma?
2

Pontosítás

tisch.david · 2011. Május. 13. (P), 17.48
Szia Poetro!

Köszönöm, hogy foglalkozol a problémával! A sematikus kód:
...
$params = array('http' => array(
		'method' => 'POST',
		'header' => "SOAPAction: $action\r\nContent-Type: text/xml; charset=UTF-8"
		'content' => $content
));
$ctx = stream_context_create($params);
$fp = @fopen('https://ejelentes.oep.hu/ejelentes/EJELSoapHttpPort', 'rb', false, $ctx);
if (!$fp) {
	echo 'Kapcsolódási hiba!';
}
$response = @stream_get_contents($fp);
if ($response === false) {
	echo 'Adatolvasási hiba!';
}
echo iconv('UTF-8', 'ISO-8859-2//IGNORE', $response);
Az így visszakapott kódot kliens oldalon egy programmal XML fájlba mentem. Ha a PHP kód Windows 7 és WAMP alatt fut, akkor az eredmény XML fájl egy részlete így néz ki:
...
    <ns0:hibas>0</ns0:hibas>
    <ns0:megjegyzes xsi:nil="1"/>
   </ns0:result>
  </ns0:getUserKasszaResponseElement>
 </env:Body>
</env:Envelope>
Ha ugyanazon a gépen soapUI-val hívom ezt a webszolgáltatást, akkor is így néz ki. Ha a linuxos szerveren fut a kód akkor meg ez az eredmény:
...
    <ns0:hibas>0</ns0:hibas>
    <ns0:megjegyzes xsi:nil=1/>
   </ns0:result>
  </ns0:getuserkasszaresponseelement>
 </env:body>
</env:envelope>
Ezen a linken tudod Te is meghívni a szolgáltatást és láthatod az eredményt.

Plusz kellemetlenség egyébként, hogy a saját virtuális linuxos szerverünkön nem is tudom futtatni a kódot, mert állandóan "failed to open stream" hibát és 400-as HTTP státusz kódot ad vissza az fopen(), hiába állítgatok User-Agent-et, meg bármit.

Köszönöm a választ!
Üdv:

Dávid
3

Hozzáférés

Poetro · 2011. Május. 13. (P), 18.03
Szerintem a kiszolgáló rétegben lehet a probléma. Azaz a SOAP szerver nem ugyanolyan választ ad. Egyébként miért van szükség iconv-al átalakítani az XML-t? Az UTF-8 sokkal könnyebben feldolgozható, és egyébként is az az alapértelmezett karakterkódolása.

Egyébként az is lehet, hogy a SOAP szerver valamiféle korlátozással él, és azért ad 400-as hibát. (mondjuk nem ártana tudni, mit is ad pontosan válasznak).
4

A kód neve: töketlenség

tisch.david · 2011. Május. 13. (P), 20.53
Szia Poetro!

Köszi a választ! Azért kell iconv-val átalakítani az XML-t, mert a kliens oldalon Magic (uniPaaS) van, ami nem kezeli az UTF-8-at. :)

Az fopen() warningja csak azt tartalmazza, hogy nem sikerült a kapcsolódás és, hogy ennek "oka" egy 400-as HTTP státusz kód. Az alapvető gond, hogy sem a szerverünket üzemeltető cég nem "tud" segíteni, sem az OEP-es üzemeltetés, a fejlesztő AlbaComp pedig számunkra elérhetetlen. :( No comment. Marad a workaround.

Üdv:

Dávid
5

iconv -> mb_convert_encoding

razielanarki · 2011. Május. 14. (Szo), 15.03
nekem gyanús az iconv hívás vmiért, volt már abból gondom, h linuxon és windowson nem ugyanúgy futott a konverzió, főleg ha //IGNORE -t és/vagy //TRANSLIT -et is tartalmazott a hívás.
6

Sajnos anélkül se...

tisch.david · 2011. Május. 15. (V), 21.03
Én is próbáltam iconv nélkül, de sajnos úgy is ugyanaz maradt az eredmény.