FlexibleFactory

I posted this on StackOverflow.com, but maybe one of out readers knows the answer…

Quite simple really:

var req:URLRequest=new URLRequest();
req.url="http://somesite.com";
var header:URLRequestHeader=new URLRequestHeader("my-bespoke-header","1");
req.requestHeaders.push(header);
req.method=URLRequestMethod.GET;
stream.load(req);

Yet, if I inspect the traffic with WireShark, the my-bespoke-header is not being sent. If I change to URLRequestMethod.POST and append some data to req.data, then the header is sent, but the receiving application requires a GET not a POST.

The documentation mentions a blacklist of headers that will not get sent. my-bespoke-header is not one of these. It’s possibly worth mentioning that the originating request is from a different port on the same domain. Nothing is reported in the policyfile log, so it seems unlikely, but is this something that can be remedied by force loading a crossdomain.xml with a allow-http-request-headers-from despite the fact that this is not a crossdomain issue? Or is it simply an undocumented feature of the Flash Player that it can only send custom headers with a POST request?

We’ve been looking into some inconsistent behaviour across platforms when making socket connections. An application that works fine in Windows and OSX fails for no apparent reason when running on Linux platforms. After running a WireShark network capture, we established that, after correctly fetching a socket policy from port 843 of the remote host, the data sent to the target port was corrupted when using Linux Flash Player.

It turns out that the culprit is the Linux implementation of Socket.writeMultiByte, at least certainly when using the “us-ascii” encoding (it’s late and we can’t be bothered to test other encodings).

So, the line:

socket.writeMultiByte("GET somepath HTTP/1.0 \r\n","us-ascii");

fails completely, with garbage getting written to the socket.

We’ve written a naive (and appropriately named) replacement which works for what we’re doing, but doesn’t handle encodings.

private function writeBetterMultiByte2(msg:String):void
{
 for(var i:int=0;i<msg.length;++i)
 {
  socket.writeByte(msg.charCodeAt(i));
 }
}

It appears that we’re not the only ones having trouble with writeMultiByte, but this time it’s with ByteArray.writeMultiByte . Something seems quite broken here.

Over at tunamedia.co.uk, we’ve released a demo of Flash movie playing Shoutcast streams using the new Sound API features available in Flash Player 10. Take a look.

We’ve been doing quite a lot of stuff using the new FileReference API that allows access to local files without server roundtrips. The current official release candidate seems to limit the allowed file size to somewhere in the region of 512k. This thread on the flash player 10 forums summarises the problem nicely. It’s led us on a bit of mission to find a more recent version of the player, which can be found here:

http://opensource.adobe.com/svn/opensource/flex/sdk/branches/3.0.x/in/player/10/

[The contents of this article are now incorrect. We've been using the players in this package and this one for linux now.]

Thankfully, this newer version does not seem to carry this FileReference limitation.

If you look through previous posts on our blog, there are a couple of posts relating to the location of the most recent player. Once again, the most recent version appears in a different location. This rather begs the question as to why new players are being littered around various places on the adobe website with no apparent consistency.

Why aren’t developers being informed of newer releases of the player that can be publicly obtained? Why are they being “hidden” in the various branches of the Flex SVN repository?