Closed GoogleCodeExporter closed 9 years ago
actually, my patch only fixes the call of the method. The result doesn't seem
to be
well parsed by the service explorer, maybe because of wrapping issues ?
Thanks for your help :)
Original comment by sylvinus
on 16 Mar 2008 at 4:59
Hi Sylvinus,
Can you provide a dump of the request and response? Either just a binary dump
of the
request, or better yet, one created with charles:
http://www.xk72.com/charles/
Original comment by evert...@gmail.com
on 24 Mar 2008 at 2:58
Hellow, I am someone else who run into the same problem. I wasn't able to use
Charles
because apparently even Charles burfs on trying to parse this Amf request and
just
shows nothing for the request (not tabs no nothing). Although I am very happy
you
pointed my attention to this great tool, thanks!
Anyway, I have a attached an old-fashioned dumped which was created using
apache_request_headers and file_get_contents('php://input'). I hope it helps.
One thing which is interesting, SabreAMF seems to work fine with the actual
requests,
it's the service browsers that seem to throw it off.
Original comment by amirab...@googlemail.com
on 24 Mar 2008 at 2:06
Attachments:
That is interesting, and would suggest the problems is not in the request, but
in the
response.. I'll check out this message and see what I can do..
A charles dump would still be great, even though it won't display you the
tabs.. It
will still have the raw data (which is what I actually need..)
But I'll first have a look without that
Original comment by evert...@gmail.com
on 24 Mar 2008 at 2:09
In that case here's Charles:
Original comment by amirab...@googlemail.com
on 24 Mar 2008 at 2:14
Attachments:
BTW it seems like the problem is with SabreAMF_AMF3_Wrapper. It is being
deserialized
and serialized correctly, but it seems that your SabreAMF_CallbackServer simply
forgot to handle it. In fact trying to use the example script under
examlpes/AMF3Client.php causes a similar error.
Original comment by amirab...@googlemail.com
on 24 Mar 2008 at 2:25
great thats good info.. there is some weird stuff going on there.. I'm
wondering if
the servicebrowser has some special handling or doesn't use the standard
remoting
components; but i'll check that out..
Original comment by evert...@gmail.com
on 24 Mar 2008 at 3:31
I have a feeling that may be that case. Note that the AmfPHP service browser
pass a
header named "serviceBrowser" with the value TRUE.
Original comment by amirab...@googlemail.com
on 24 Mar 2008 at 4:09
Original comment by evert...@gmail.com
on 24 Mar 2008 at 7:56
Hi amirabiri,
The 'amfmessage' file decodes just fine, just like you said..
I can't actually open the charles file though.. I'm running the latest 3.1.4,
what
version did you create it with? Also, it might help to zip it beforehand, maybe
uploading it mangles it somehow (but I doubt that..)
Original comment by evert...@gmail.com
on 24 Mar 2008 at 8:08
Also, any idea where I can fetch a copy of the swx servicebrowser source?
Original comment by evert...@gmail.com
on 24 Mar 2008 at 8:12
I just downloaded the latest version of Charles, which is 3.2, today because you
mentioned it... :-) anyway if you want me to create a dump with 3.1.x just let
me know.
I have attached a rared version.
Don't know about SWX I'm affraid.
Original comment by amirab...@googlemail.com
on 24 Mar 2008 at 8:50
Attachments:
Sorry bout that.. charles didn't automatically update.. I'm downloading the
latest
version myself now too :)
Original comment by evert...@gmail.com
on 24 Mar 2008 at 9:06
Hi,
The dump works, thanks a lot.. Investigating this issue has lead me to some
weird
string referencing issues in AMF3..
I'll hopefully have a better reply soonish
Evert
Original comment by evert...@gmail.com
on 24 Mar 2008 at 10:15
What I'm not sure of, is if this will fix your problem..
do hope so though
Original comment by evert...@gmail.com
on 24 Mar 2008 at 10:20
Can you attach the fix?
BTW I'm using 1.0.174. I hope you intend to incorporate the fix to 1.0.
Original comment by amirab...@googlemail.com
on 24 Mar 2008 at 11:22
Try the current SVN version, this will fix an AMF3 reference issue, I hope this
also
solves yours..
Original comment by evert...@gmail.com
on 25 Mar 2008 at 12:31
The problem was not solved, as we suspected.
The problem is basically that the above request is parsed as a
SabreAMF_AMF3_Wrapper,
but SabreAMF_CallbackServer does not seem to handle this message anywhere. I
have
fixed the problem by adding some code to handle a SabreAMF_CallbackServer to
SabreAMF_CallbackServer->exec(). I have attached a diff (SabreAMF.diff).
However, after that problem is tackled, amfphp's browser still fails. So I did
some
tricks to get the exact same request with the exact same response by both
AmfPHP and
SabreAMF (attached: gateways.chls). The only difference between the two
reuquest/response pairs is the way the gateway hadnles them. In both cases the
actual
return value of the service function is the same, which in PHP terms is:
Array
(
[0] => Array
(
[login] => Array
(
[description] => Performs a login attempt for username $username
with password $password.
[arguments] => Array
(
[0] => username - string username
[1] => password - string password
)
[access] => private
)
[logout] => Array
(
[description] => Logouts the user. All session data is cleared.
[arguments] => Array
(
)
[access] => private
)
)
[1] => Session actions.
)
Which is the format the AmfPHP's browser expects for a describeServer request.
The only difference I can see between the two responses is that AmfPHP seems to
return multiple response bodies, while SabreAMF still returns only one. Other
then
that the two request/responses pairs appear to be identical.
A
Original comment by amirab...@googlemail.com
on 26 Mar 2008 at 2:42
Attachments:
So this is odd..
It's clear what you're doing in the CallbackServer.diff, you're getting an
AMF3_Wrapper object, and only grabbing the inner data..
However, if you trace all that back a little bit...
The $request variable comes from SabreAMF_Server::getRequests()
That method, in turn, gets its data from SabreAMF_Message::getBodies(), which
gets it
from the private variable bodies.
That variable is populated after the deserialize() method.. If you look at line
153
in SabreAMF_Message, you'll see that what you did in CallbackServer, is already
done
there as well..
The differences in the 2 requests in the charles dump you sent me makes perfect
sense.. The reason you're getting 2 bodies from AMFPHP, is because they
implemented
onDebugEvents, which doesn't come standard in SabreAMF..
Its not that I don't believe you, but it definitely has me confused.. In any
case I
feel the SabreAMF_AMF3_Wrapper handling should all happen within
SabreAMF_Message
(like it pretty much should be right now)
I'm going to use your request and try to copy the exact situation, to see what
happens..
Original comment by evert...@gmail.com
on 26 Mar 2008 at 4:13
Yes, but the problem is that the wrapper never comes into play. It's not a
subclass
of SabreAMF_Message, so it is not picked up as an AMF3 message and the
execution path
just continues to try and handle it like an AMF0 message, which is obvious
completely
inadequate.
If AmfPHP's browser is sending non-standard messages then it's a different
debate
whether or not you want to also break the standard. However, I doubt that
AmfPHP's
browser does that, because it is based on Flex itself, so I'm guessing they
just use
the library normally.
Original comment by amirab...@googlemail.com
on 29 Mar 2008 at 8:50
Found the issue on 2 places..
Can you give the latest SVN version a shot?
I won't create a release just yet, as I want to do some improvement in the
general
framework.. The AMF0/AMF3/AMF3+RemoteObject handling is too scattered and
should be
centralized more
Original comment by evert...@gmail.com
on 29 Mar 2008 at 10:00
Hi,
I had the time to test the latest SVN. The input problem is fixed, the method
gets
called correctly. thanks for that!
However, the response still isn't displayed in the service explorer. So is it an
explorer bug or a sabreamf one?
anyone got the explorer working with sabreamf?
thanks!!
Original comment by sylvinus
on 16 Apr 2008 at 3:53
Hi Sylvinus,
I looked at the charles session again you sent earlier.. The first thing that
catches
my eye, is that there's a slight difference between the objects sent back from
amfphp, and SabreAMF.. First thing I would try is matching the returned
structure
exactly..
The main difference I see are the 'logout' and 'login' objects. Those objects
are
identified as Mixed Arrays in charles for SabreAMF, but its an Object in the
AMFPHP
result.
Original comment by evert...@gmail.com
on 16 Apr 2008 at 1:50
The bug that had been identified here has been fixed, but another issue
mentioned is
not considered a SabreAMF bug and I believe this is due to the fact SabreAMF
has a
different encoding strategy for certain data-types.. If you still feel this is
in
fact a bug in SabreAMF, and you're not able to match the exact data-structure
from
AMFPHP, let me know..
Although SabreAMF's encoding strategy is different, it should provide the
ability to
encode to every desirable as-type.
Original comment by evert...@gmail.com
on 16 Sep 2008 at 10:56
Original issue reported on code.google.com by
sylvinus
on 16 Mar 2008 at 4:32