[Laszlo-user] XML RPC requests return a "application/x-shockwave-flash" data type

Tue Mar 25 21:04:39 PDT 2008

Hi 

Does anyone have a piece of javascript (or Java) that will actually do this decoding? I mean turn the SWF binary format back into the original data - in our case an xml string ? 

Let me explain our use case: 

    • we are creating a JMeter test, we make requests and record the responses 
    • we need to look into the response for various reasons (check them for validity, extract IDs and keys used later in the test) 
    • JMeter has built-in facilities for understanding strings and XML, but not SWF 
    • However JMeter also has a general facility to run javascript on the response (its a "BeanShell") 
    • Essentially we can do a getBytes or getResponseAsString and feed that into whatever javascript you give us 

We need a js code snippet that will take the SWF bytes and turn them back to XML string, in the JMeter BeanShell. 

I am sure OL has this code somewhere because OL is decoding this format already today. Question is - can you give us a clean code snippet that will do it in the JMeter BeanShell ? 

(or any other ideas on how to achieve this goal in JMeter) 

Thanks 

Gilad 

Gilad Parann-Nissany 

----- Original Message ----- 
From: "Henry Minsky" <henry.minsky at gmail.com> 
To: "Gilad Parann-Nissany" <gilad.parann.nissany at g.ho.st> 
Cc: "laszlo-user" <laszlo-user at openlaszlo.org>, "Yazan Ghandour" <Yazan.Ghandour at corp.g.ho.st>, "Rami Khalayleh" <Rami.Khalayleh at corp.g.ho.st>, "Anas Jadallah" <Anas.Jadallah at corp.g.ho.st>, "Elias Khalil" <Elias.Khalil at corp.g.ho.st> 
Sent: Tuesday, March 25, 2008 4:27:52 PM (GMT+0200) Auto-Detected 
Subject: Re: [Laszlo-user] XML RPC requests return a "application/x-shockwave-flash" data type 

Yes, the javascript data is compiled down to swf byte codes which, when executed, recreate that data. 

For example, a list of numbers [1,2,3] compiles to something like 

push 1 
push 2 
push 3 
push 3 
new Array 

or whatever the equivalent is in the SWF instruction set 

On Tue, Mar 25, 2008 at 10:23 AM, Gilad Parann-Nissany < gilad.parann.nissany at g.ho.st > wrote: 

Hi 

In our case it can be pretty big, we do need the performance. 

So the actual response format is truly binary (SWF) and not XML at all? in that case the content-type is correct I guess. 

or is it text wtih just the encoding set to SWF? in that case I guess we could figure a workaround? 

Thank you! 

Gilad 

Gilad Parann-Nissany 

----- Original Message ----- 
From: "Henry Minsky" < henry.minsky at gmail.com > 
To: "Gilad Parann-Nissany" < gilad.parann.nissany at g.ho.st > 
Cc: "laszlo-user" < laszlo-user at openlaszlo.org >, "Yazan Ghandour" < Yazan.Ghandour at corp.g.ho.st >, "Rami Khalayleh" < Rami.Khalayleh at corp.g.ho.st >, "Anas Jadallah" < Anas.Jadallah at corp.g.ho.st >, "Elias Khalil" < Elias.Khalil at corp.g.ho.st > 
Sent: Tuesday, March 25, 2008 3:53:16 PM (GMT+0200) Auto-Detected 
Subject: Re: [Laszlo-user] XML RPC requests return a "application/x-shockwave-flash" data type 

The issue is that the implementation in swf was written to compile the return data as a Flash swf binary file. The implementation for DHTML uses a JSON encoding. The fix for this would need to be to switch to using the JSON encoding with the swf runtime. We do have a JSON parser for SWF7/8, it would be somewhat slower than the direct-to-swf transport being used now, but that might be acceptable if the amount of data you are sending in each request is not very large. 

On Tue, Mar 25, 2008 at 9:33 AM, Gilad Parann-Nissany < gilad.parann.nissany at g.ho.st > wrote: 

Hi all 

We have an app using Laszlo XML RPC rather heaviliy, our version is 4.0.8. 

Looking at the logs one sees that the REQUESTS produced by our client for XML-RPC are of type "application/x-www-form-urlencoded" 

(which makes sense - it is the correct content-type for a POST request). 

However the RESPONSEs are of type "application/x-shockwave-flash" which is strange. 

We would expect the reponse type to be text/xml or something like that. This is creating a real-world problem for us on various consumers e.g. JMeter - which expect the text/xml to function correctly. 

Do you have any experience with this issue? Suggestions or workarounds? 

Detailed info from the logs is below. 

Thanks 

Gilad 

P.S. For example: something like the following response headers 

---------------- 

HTTP/1.1 200 OK 
Expires: Fri, 05 Oct 2001 00:00:00 GMT 
Date: Tue, 25 Mar 2008 11:51:13 GMT 
Server: Apache-Coyote/1.1 
Cache-Control: no-store 
Content-Type: application/x-shockwave-flash 
Content-Length: 437 
Server: Apache-Coyote/1.1 

---------------- 

is returned from the following request: 

---------------- 

POST http://localhost/lps/workspace/VC/client/welcomei.lzx?__lzbc__=1205615513625 

POST data: 
fpv=9%2E115&lzr=swf8&proxied=true&lzpostbody=%3C%3Fxml+version%3D%221%2E0%22%3F%3E%0A%3CmethodCall%3E%0A%3CmethodName%3EClientInfo%2EgetGhostInitInfo%3C%2FmethodName%3E%0A%3Cparams%3E%0A%3Cparam%3E%0A%3Cvalue%3E%3Cstring%3E%3C%2Fstring%3E%3C%2Fvalue%3E%0A%3C%2Fparam%3E%0A%3C%2Fparams%3E%0A%3C%2FmethodCall%3E&headers=Content%2DType%3A+text%2Fxml&url=xmlrpc%3A%2F%2Flocalhost%2Fvcweb%2FGhostXmlrpc&reqtype=POST&lzt=data&ccache=false&cache=false&sendheaders=false 

Cookie Data: 
JSESSIONID=2FEEB2B9C6B91302795CD62AD3D274A6 

Request Headers: 
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) 
Host: localhost 
Accept-Encoding: gzip, deflate 
Accept-Language: he-IL 
Pragma: no-cache 
Content-Type: application/x-www-form-urlencoded 
UA-CPU: x86 
Accept: */* 
Content-Length: 462 
Connection: keep-alive 
Referer: http://localhost/lps/workspace/VC/client/welcomei.lzx?lzt=swf&lzr=swf8 
x-flash-version: 9,0,115,0 

Gilad Parann-Nissany 

-- 
Henry Minsky 
Software Architect 
hminsky at laszlosystems.com 

-- 
Henry Minsky 
Software Architect 
hminsky at laszlosystems.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-user/attachments/20080325/0794693a/attachment.html