incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarosław Szczepankiewicz <jszczepankiew...@gmail.com>
Subject Re: HTTPService woes
Date Thu, 26 Apr 2012 13:51:15 GMT
As far as I know, the limitation of using only GET / POST is from old
netscape plugin api, adobe cannot make more that api gives. Plugin api
does not allow passing something other that GET / POST. In our
application (flex with REST) we used tunneling by using POST with
custom headers, please take a look at:

X-HTTP-Method-Override

2012/4/26 Brett Adam <bpjadam@gmail.com>:
> Michael et. al:
>
> It's not just the player. There's definitely evildoing in the HTTPService classes as
well.
>
> A long long time ago I became very unhappy with the HTTPService class and friends that
constantly fought me at every turn.
>
> All I wanted was a nice, clean pathway to making RESTful calls from my Flex apps.
>
> Oh, but yes. I wanted headers. I wanted PUT and DELETE. I wanted my own content-types.
I wanted things that (apparently) I should not want.
>
> GET's were being stripped of headers. GET requests of novel content types were turned
into POST requests. POST requests with no body were turned back into GET requests. PUT and
DELETE were turned into POST.
>
> Perversions abounded.
>
> I thought maybe it was just Flash Player in the browser that was living with constraints.
But AIR was similarly damaged.
>
> After much workaround effort with nasty POST "tunneling" strategies inspired by the RoR
community (?_method=GET !!!! ) I hacked my way into the bowels of the darn HTTPService layer
and cobbled a monkey patch to force URLLoader to honor the originally requested method after
all the other HTTPxxx classes had done their worst.
>
> I wrote a few posts back when…   http://verveguy.blogspot.com/2008/07/truth-about-flex-httpservice.html
>
> I've attached a slightly trimmed down set of files that implement my hack-around (removing
unrelated stuff).  I note that this solves the method problem, but not necessarily the header
issues.
>
> Since I trimmed them, I may have busted something compilation-wise. Sorry, but I don't
have a clean way to test this independently at the moment.
>
> Let me know if this makes sense. The basic thrust is to ultimately insert a subclass
of URLLoader way down deep in the call chain that puts the HTTP method *back* to whatever
was originally requested after it's been willfully changed by the innards of Adobe's implementation.
>
> Yes, it would be much cleaner to fix this in the SDK. There's quite a lot of special
case logic in the SDK classes that would need to be carefully unraveled and/or purged. Plenty
of "oh, if this, then whack the method to be GET" and stuff that frankly, I can't see any
good reason for these days. I'm *assuming* it was ancient browser limitations that led to
what smells like legacy code.
>
> It would be almost fun to fix this properly in the SDK now that it's more open than before.
Happy to help anyone game to take that on - with a first request that there be strong unit
tests in place before we begin.
>
>
>
>
> -- Brett
>
>
> On Apr 25, 2012, at 3:43 PM, Michael A. Labriola wrote:
>
>>> I most certainly will, Justin.  This has been a dismaying experience to find
that the flagship service class has such a glaring glitch.
>>
>> I fear that, when looking deeper, you may find it is the Flash Player and not the
service class that is your root cause, but I would be very happy to be wrong.
>>
>> Mike
>>
>>
>
>

Mime
View raw message