incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Adam <>
Subject Re: HTTPService woes
Date Thu, 26 Apr 2012 13:44:52 GMT
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…

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

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.

View raw message