[PHP/SOAP] SoapServer wijzigt \r\n naar \n

[RobIII]

Ik gebruik een PHP SoapServer om Soap calls af te handelen in een project. De client is een in C# geschreven applicatie welke mbv een web reference/wsdl de Soap calls maakt.

Nu blijkt dat als ik een multi-line string (in windows is dat dus \r\n aan 't eind van de regel) vanuit de client naar de server stuur dat er enkel een \n (uiteindelijk) in de database terecht komt.

Ik heb toen alle \r's vervangen door #R# en alle \n's door #N# om zo te zien of de \r uberhaupt goed binnen kwam in de methode die de SoapServer aanroept. Wat blijkt? De \r is dan al verdwenen. Dus; dan zit ergens in het transport ofwel in de SoapServer. Om dat uit te sluiten heb ik het netwerk verkeer gesniffed en daaruit blijkt dat de \r\n (0x0D0A) wel degelijk in de Soap call zit naar de server toe.

De call word als volgt afgehandeld:

PHP:

...
//Handle SOAP request
$soap = new SoapServer('http://localhost/wsdl', array('soap_version' => SOAP_1_2, 'encoding' => 'UTF-8'));
$soap->setClass($class, $foo);
$soap->handle();
...

PHP:

//Deze functie wordt door SoapServer gecalled
public function Foo($id, $mystring) {
  $mystring = str_replace("\r", "#R#", $mystring)
  $mystring = str_replace("\n", "#N#", $mystring)
  //Hier blijkt er enkel een #N# in $mystring te staan
}

Daar lijkt me dus weinig aan te veranderen wat een oplossing zou (kunnen) bieden voor mijn probleem. Misschien dat in de SoapServer constructor nog een optie meegegeven kan worden die mijn probleem verhelpt, maar die zijn zover ik kan zien niet gedocumenteerd De karige info die ik wél her-en-der vind is als volgt:

options
Allow setting a default SOAP version (soap_version), internal character encoding (encoding), and actor URI (actor).

The classmap option can be used to map some WSDL types to PHP classes. This option must be an array with WSDL types as keys and names of PHP classes as values.

The typemap option is an array of type mappings. Type mapping is an array with keys type_name, type_ns (namespace URI), from_xml (callback accepting one string parameter) and to_xml (callback accepting one object parameter).

Other options are features and cache_wsdl.

Waar die 'features' dan gedocumenteerd zijn is mij een raadsel... (Man, wat hou ik van MSDN ). Misschien dat ik 't over het hoofd zie, maar ik kan er niets over vinden.

Ik heb even zitten googlen om te zien of in de WSDL nog wat zaken gezet zouden kunnen worden (zoals xml:space of preserveWhiteSpace) maar ik kan daar ook weinig zinnigs over vinden; daarbij: de \r\n gaan wel degelijk naar de server in de call. Maar de functie ontvangt de parameter dus zonder \r.

Mogelijke workarounds:

• Ik weet, server-side, waar ik multiline strings kan verwachten; daar kan ik natuurlijk een replace('\n', '\r\n', $mystring) op los laten...
• Ik kan in de client, waar ik multiline texboxes gebruik, een usercontrol inheriten van een textbox control en die de replace \n -> \r\n laten uitvoeren
• Ik kan een "magic value" gebruiken i.p.v. \r\n
• Etc. etc.

Allemaal totaal niet wenselijke workaround; ik wil verdorie die \r\n die ik stuur ook gewoon weer terug krijgen en PHP moet met z'n takke van m'n data afblijven Omdat ik databinding gebruik op de textboxes in mijn form heb ik geen zin om daar "speciaal voor multiline textboxes" nog eens tussen te gaan zitten om die \r er tussen te frotten en doe ik dat niet dan worden er blokjes weergegeven omdat de (normale) textboxes een \r\n verwachten en dus geen \n...

[ Voor 8% gewijzigd door RobIII op 02-06-2009 15:00 . Reden: Typo in 2e code blok :X ]

[Matis]

Ik herken je probleem wel, we hebben een tijd geleden voor school strings over een netwerk gestuurd van een linux c++ code naar een windows c# code. Daar kwamen van linux --> windows geen \r's door.

De enige manier om dit probleem te omzeilen was \r\r\n in te voeren, waardoor de eerste \r (of de tweede) weggekapt werd en er dus wel *netjes* \r\n achteraan stond.

Maar je zegt dat je een PHP SOAP server hebt, waar de berichten verrot aankomen. Ik zal eens ff koeken of ik iets op mn digitale boekenplank heb staan!

Edit
ik hoop dat dit een typo is:

PHP:

$mystring = str_replace("\r'" "#R#", $mystring)

Ik zie daar een single quote staan

* Matis zwaait naar Snake

[ Voor 14% gewijzigd door Matis op 02-06-2009 14:55 ]

[Snake]

PHP:

  $mystring = str_replace("\r'" "#R#", $mystring)

Is die ' na die \r een typo?

[RobIII]

Matis schreef op dinsdag 02 juni 2009 @ 14:46:
De enige manier om dit probleem te omzeilen was \r\r\n in te voeren, waardoor de eerste \r (of de tweede) weggekapt werd en er dus wel *netjes* \r\n achteraan stond.

En dat probeer ik dus juist te voorkomen Maar, ik heb het voor de gein eens even getest en \r\r\n blijkt \n\n te worden Fijn

Snake schreef op dinsdag 02 juni 2009 @ 14:54:

PHP:

  $mystring = str_replace("\r'" "#R#", $mystring)

Is die ' na die \r een typo?

Jep. Typo. My bad.

[ Voor 20% gewijzigd door RobIII op 02-06-2009 14:55 ]

[Little Penguin]

Wordt het probleem niet veroorzaakt door de deserialisatie van XML, waarbij de whitespace aangepast wordt - is het wel gedefinieerd wat er moet gebeuren met CRLF als deze in XML staat? Mag deze niet stiekem ingeslikt worden???

[RobIII]

Little Penguin schreef op dinsdag 02 juni 2009 @ 14:54:
Wordt het probleem niet veroorzaakt door de deserialisatie van XML, waarbij de whitespace aangepast wordt - is het wel gedefinieerd wat er moet gebeuren met CRLF als deze in XML staat?

Waarom gaat het dan wel goed als ik een "uitgaande" \n vervang door \r\n (server-side dus)? Als ik in de DB een \n vervang door \r\n (wat 't dus hoort te zijn) en ik vraag in mijn client dat record op krijg ik netjes \r\n terug. De \r wordt dus door SoapServer->handle() gestript voordat de functie wordt aangeroepen?

Little Penguin schreef op dinsdag 02 juni 2009 @ 14:54:
Mag deze niet stiekem ingeslikt worden???

Ja, daar heb je dus die urn:space of preserveWhitespace voor, maar ik zou niet weten waar ik die in zou moeten zetten. In de WSDL? In de Soap envelope, en hoe dan? En waarom wordt de \n dan wel behouden? Die zou dan, volgens mij, ook genegeerd moeten worden?

[ Voor 45% gewijzigd door RobIII op 02-06-2009 15:11 ]

[flashin]

Als dat zo zou zijn, probeer dan eens via NuSOAP een server op te zetten? Dat heb je ook zo getest natuurlijk


PHP Soap is echt extreem bagger gedocumenteerd.

[ Voor 19% gewijzigd door flashin op 02-06-2009 15:00 ]

[Matis]

http://bytes.com/groups/n...turn-webmethod-parameters Hier is het probleem precies andersom, maar toch wel hetzelfde

As a workaround you can try to encode strings you are sending using base64
or similar encoding or parse them back and replace \r to \r\n after
de-serialization is done.

Fatsige workaround!

[ Voor 3% gewijzigd door Matis op 02-06-2009 15:00 ]

[Tiemez]

PHP:

function newlines( $str ) {

    return str_replace("<br />", "\r\n", nl2br( $str ) );
}

$var = newlines( "hallo\r\n" ); 
$var = newlines( "hallo\n");

geven beiden "hallo\r\n" terug.

[RobIII]

Matis schreef op dinsdag 02 juni 2009 @ 14:59:

Fatsige workaround!

Precies; en dat wil ik nou net niet.

Tiemez schreef op dinsdag 02 juni 2009 @ 15:00:

PHP:

function newlines( $str ) {

    return str_replace("<br />", "\r\n", nl2br( $str ) );
}

$var = newlines( "hallo\r\n" ); 
$var = newlines( "hallo\n");

geven beiden "hallo\r\n" terug.

Ook een ranzige workaround Daarbij is <br /> in dit geval gewoon een "magic value" want ik zit in een winforms applicatie die niets doet met br's (ik begrijp dat je code enkel "server side" gebruikt worden en nooit bij de client zouden komen, maar als ik, in de client, een <br /> in mijn string wil zetten wil ik dat wel gewoon kunnen zonder dat er een \r\n van wordt gemaakt )

flashin schreef op dinsdag 02 juni 2009 @ 14:58:
Als dat zo zou zijn, probeer dan eens via NuSOAP een server op te zetten? Dat heb je ook zo getest natuurlijk

Stél dat het de oplossing is dan heb ik er niets aan; ik zit vast aan PHP's SoapServer... (en daarbij heb ik te weinig controle over die machine om NuSoap te installeren).

[ Voor 85% gewijzigd door RobIII op 02-06-2009 15:05 ]

[Matis]

Je icon past mooit bij je toestand

Er wordt veel gesproken over het carriage return in SOAP.

http://www.google.nl/sear...+return&btnG=Zoeken&meta=

Komt het met wireshark wel goed binnen?

Edit:
Het probleem doet zich voor onder elke programmeer taal lijkt het wel. Het enige remedie is een van je workarounds toepassen.

[ Voor 23% gewijzigd door Matis op 02-06-2009 15:07 ]

[RobIII]

Matis schreef op dinsdag 02 juni 2009 @ 15:06:
Je icon past mooit bij je toestand

Wie heeft dat gedaan?

Matis schreef op dinsdag 02 juni 2009 @ 15:06:
Komt het met wireshark wel goed binnen?

Jep:

RobIII schreef op dinsdag 02 juni 2009 @ 14:40:
Dus; dan zit ergens in het transport ofwel in de SoapServer. Om dat uit te sluiten heb ik het netwerk verkeer gesniffed en daaruit blijkt dat de \r\n (0x0D0A) wel degelijk in de Soap call zit naar de server toe.

[Matis]

Woeps my bad. Ik heb voor PHP SOAP altijd het Zend Framework gebruikt, maar ik ben nooit tegen een dergelijk probleem aan gelopen (heb het ook nooit nodig gehad).

Sorry

[Apen-nootjes]

RobIII schreef op dinsdag 02 juni 2009 @ 15:01:
[...]

Precies; en dat wil ik nou net niet.

[...]

Ook een ranzige workaround Daarbij is <br /> in dit geval gewoon een "magic value" want ik zit in een winforms applicatie die niets doet met br's (ik begrijp dat je code enkel "server side" gebruikt worden en nooit bij de client zouden komen, maar als ik, in de client, een <br /> in mijn string wil zetten wil ik dat wel gewoon kunnen zonder dat er een \r\n van wordt gemaakt )


[...]

Stél dat het de oplossing is dan heb ik er niets aan; ik zit vast aan PHP's SoapServer... (en daarbij heb ik te weinig controle over die machine om NuSoap te installeren).

AFAIK is NUSoap gewoon een PHP bestand (class) die je alleen maar in dezelfde dir hoeft te zetten als je andere PHP bestanden... Lijkt me dat je daar wel genoeg rechten voor hebt En ik kan beamen: NuSoap is een stuk beter

[RobIII]

Apen-nootjes schreef op dinsdag 02 juni 2009 @ 15:11:
[...]

AFAIK is NUSoap gewoon een PHP bestand (class) die je alleen maar in dezelfde dir hoeft te zetten als je andere PHP bestanden... Lijkt me dat je daar wel genoeg rechten voor hebt En ik kan beamen: NuSoap is een stuk beter

En is dat een in-place replacement? Want ik heb geen zin om alles om te moeten gaan schrijven naar NuSoap...

* RobIII even NuSoap documentatie gaat doornemen

edit:
Hmmm: Last Update: Nov 06 2007 Lijkt stil te staan? Of is 't "perfect"?

[ Voor 8% gewijzigd door RobIII op 02-06-2009 15:13 ]

[LuCarD]

Volgens deze link en post is het gedaan bij design.

http://social.msdn.micros...0-4910-be10-6594dff56de4/

Aangezien de XML Specificatie zegt dat je alleen maar \n ( ASCII #A ) mag gebruiken voor regeleinde.
http://www.w3.org/TR/2000/REC-xml-20001006#sec-line-ends

[Matis]

RobIII schreef op dinsdag 02 juni 2009 @ 15:12:
[...]

edit:
Hmmm: Last Update: Nov 06 2007 Lijkt stil te staan? Of is 't "perfect"?

http://framework.zend.com/manual/en/zend.soap.html

Last updated 28 mei 2009
meuk: Zend Framework 1.8.2

@Hierboven: Tja, dat kwam ik ook net tegen, maar hier staat dat het wel weer mag; Zowel D als A http://www.w3.org/TR/REC-xml/#sec-line-ends
XML 1.0

[ Voor 17% gewijzigd door Matis op 02-06-2009 15:19 ]

[RobIII]

LuCarD schreef op dinsdag 02 juni 2009 @ 15:13:
Volgens deze link en post is het gedaan bij design.

http://social.msdn.micros...0-4910-be10-6594dff56de4/

Aangezien de XML Specificatie zegt dat je alleen maar \n ( ASCII #A ) mag gebruiken voor regeleinde.
http://www.w3.org/TR/2000/REC-xml-20001006#sec-line-ends

Klopt en eensch. Maar waarom gaat het dan wel goed "de andere kant op" (dus een \r\n vanuit de server sturen naar de client wordt wél behouden).

Matis schreef op dinsdag 02 juni 2009 @ 15:18:
http://framework.zend.com/manual/en/zend.soap.html

Last updated 28 mei 2009
meuk: Zend Framework 1.8.2

Ga ik ook even naar kijken... Ik ben niet echt thuis in PHP, maar die moet toch mee gecompiled worden ofzo?

[ Voor 25% gewijzigd door RobIII op 02-06-2009 15:22 ]

[Verwijderd]

Welk probleem probeer je op te lossen? HTML of eender welke XML variant maakt (behalve bij multiline tekstblokken) geen onderscheid tussen \r\n of \n of ' ' of \t of wat voor whitespace dan ook.
Als je iets dergelijks wilt opslaan maakt het dus (bij nette code) niet uit of je nou een \n of \r\n opslaat.
Als je data wilt opslaan gebruik dan geen unencoded strings, gebruik uuencode of base64 codering.
Een andere oplossing is om je bytestream niet als een string te lezen, maar als een bytestring (met bijvoorbeeld getc() of fread() achtige functies, i.p.v. scanf() gets() achtige).
Een minder strakke oplossing is door bij iedere \n een \r toe te voegen voor opslaan of direct na uitlezen. Als je onderscheid maakt tussen \n of \r\n is het dus een binaire datastroom.

[RobIII]

Punt is dat ik gewoon databinding gebruik op mijn textboxes en mbv een web reference de soap-call uit voer. Er zijn weinig plekken (behalve in de PHP) waar ik die \r kan afhandelen/terug frotten (of ik moet moeilijk gaan doen).

[ Voor 7% gewijzigd door RobIII op 02-06-2009 15:25 ]

[LuCarD]

RobIII schreef op dinsdag 02 juni 2009 @ 15:20:
[...]

Klopt en eensch. Maar waarom gaat het dan wel goed "de andere kant op" (dus een \r\n vanuit de server sturen naar de client wordt wél behouden).

Misschien een bug in de server?

Ga ik ook even naar kijken... Ik ben niet echt thuis in PHP, maar die moet toch mee gecompiled worden ofzo?

Nope. het is een Framework Library die je moet includen.

[Matis]

LuCarD schreef op dinsdag 02 juni 2009 @ 15:25:
Nope. het is een Framework Library die je moet includen.

Klopt; Iets in de trant van:

PHP:

require_once('Zend/Soap/Server.php');
$server = new Zend_Soap_Server(null, $options);
// Bind Class to Soap Server
$server->setClass('MyClass');
// Bind already initialized object to Soap Server
$server->setObject(new MyClass());
...
$server->handle();

[RobIII]

hmmm Ik heb 'm nu met Zend_Soap_Server aan de praat, maar die heeft hetzelfde... (wat overigens, inderdaad nogal wiedes is):

Nu heb ik Server.php (voor de test) even "gepatched":

PHP:

    public function handle($request = null)
    {
        if (null === $request) {
            $request = file_get_contents('php://input');
        }

        ...
        ...
        try {
            $request = str_replace("\r", "#R#", $request);
            $request = str_replace("\n", "#N#", $request);
            $this->_setRequest($request);
        } catch (Zend_Soap_Server_Exception $e) {
        ...
        }
        ...
        ...

De \r\n zit er dus wel degelijk in. Nu nog een optie ontdekken die een preserveWhitespace effect heeft... ik heb gewoon geen zin om overal te-pas-en-te-onpas die \r te moeten 'vangen'/'escapen' etc; zeker omdat ik gewoon databinding gebruik zonder daar zelf veel tussen te zitten.

Ik heb in de WSDL ook al een xml:space="preserve" op de parameter gezet, maar ook dat haalt niets uit.

De types naar xsd:base64Binary helpt dan weer wel en hoef ik alleen maar in de client aanpassingen te maken; maar dan kan ik voor die ene stomme textbox dus weer geen databinding gebruiken...

Met een databinding met een format event kan ik 't wel oplossen door in dat format event de \n te vervangen door \r\n maar da's zo lelijk...

[ Voor 33% gewijzigd door RobIII op 02-06-2009 16:57 ]

[RobIII]

Goed; ik heb 't voorlopig (wil er niet te veel tijd aan besteden) maar zo opgelost:

C#:

    public class SoapMultilineHandlerBinding : Binding
    {
        public SoapMultilineHandlerBinding(string propertyName, object dataSource, string dataMember)
            : base(propertyName, dataSource, dataMember) { }

        protected override void OnFormat(ConvertEventArgs cevent)
        {
            base.OnFormat(cevent);
            if (cevent.DesiredType == typeof(string))
            {
                string v = cevent.Value.ToString();
                if (v.Contains("\n") && !v.Contains("\r"))
                    cevent.Value = v.Replace("\n", "\r\n");
            }
        }

        protected override void OnParse(ConvertEventArgs cevent)
        {
            base.OnParse(cevent);
            if (cevent.DesiredType == typeof(string))
            {
                string v = cevent.Value.ToString();
                if (v.Contains("\n") && v.Contains("\r"))
                    cevent.Value = cevent.Value.ToString().Replace("\r\n", "\n");
            }
        }
    }

...
...
//Gebruik:
this.Companyname.DataBindings.Add(new Binding("Text", this.Contact, "companyname"));  //Zo zijn alle andere bindings
this.Address.DataBindings.Add(new SoapMultilineHandlerBinding("Text", this.Contact, "address")); //En zo zijn de "multiline" bindings

Mooi is 't niet, maar ik kan iig verder...

Overigens: spaties vooraan/achteraan een string, die officieel ook zouden moeten wegvallen blijven wél behouden, dus er is al "ergens" een preserveWhitespace achtig-iets in werking

[ Voor 17% gewijzigd door RobIII op 02-06-2009 17:38 . Reden: IETS defensievere versie van SoapMultilineHandlerBinding class ]

[ID-College]

Ach, er zijn wel ergere dingen in het leven.
Als het echt niet anders kan dan is het niet anders.