Finally received some attention from Adobe and got an answer on this. The problem with long HTTP Authentication headers is that, by default, the Base64Encoder class will inject newline characters every 72 characters. Obviously that causes a chunk of the base-64 encoded string to be interpreted as a new header attribute, which causes the error.
You can fix this by setting (in the above example) encoder.insertNewLines = false;
The default setting is true.
I've fixed the above code to work for arbitrarily long Authentication strings.
Tracking it down
At first I thought this was a coercion bug where null
was getting coerced to "null"
and a test of "null" == null
was passing. It's not. I was close, but so very, very wrong. Sorry about that!
I've since done lots of fiddling on wonderfl.net and tracing through the code in mx.rpc.xml.*
. At line 1795 of XMLEncoder
(in the 3.5 source), in setValue
, all of the XMLEncoding boils down to
currentChild.appendChild(xmlSpecialCharsFilter(Object(value)));
which is essentially the same as:
currentChild.appendChild("null");
This code, according to my original fiddle, returns an empty XML element. But why?
Cause
According to commenter Justin Mclean on bug report FLEX-33664, the following is the culprit (see last two tests in my fiddle which verify this):
var thisIsNotNull:XML = <root>null</root>;
if(thisIsNotNull == null){
// always branches here, as (thisIsNotNull == null) strangely returns true
// despite the fact that thisIsNotNull is a valid instance of type XML
}
When currentChild.appendChild
is passed the string "null"
, it first converts it to a root XML element with text null
, and then tests that element against the null literal. This is a weak equality test, so either the XML containing null is coerced to the null type, or the null type is coerced to a root xml element containing the string "null", and the test passes where it arguably should fail. One fix might be to always use strict equality tests when checking XML (or anything, really) for "nullness."
Solution
The only reasonable workaround I can think of, short of fixing this bug in every damn version of ActionScript, is to test fields for "null" and
escape them as CDATA values.
CDATA values are the most appropriate way to mutate an entire text value that would otherwise cause encoding/decoding problems. Hex encoding, for instance, is meant for individual characters. CDATA values are preferred when you're escaping the entire text of an element. The biggest reason for this is that it maintains human readability.
Best Answer
You want to choose from 2 api combos to accomplish this.
Version 1 is URLLoader and FileStream
Using this combination of class, you would load the file from your server in to air via the URLLoader object. This will download the file in to memory and then notify you when the download is complete. Make sure you initiate the download with a dataFormat of URLLoaderDataFormat.BINARY. You would then initiate a Filestream object and write it out to the disk using writeBytes().
Version 2 is URLStream and FileStream
URLStream is very similar to URLLoader, but instead of waiting for the file to completely download before using the result, data is made available to you during the download. This method works well for large files because you don't have to wait for the full download to start saving it to disk, and you also save on memory since once the player hands it off to you it can release the memory related to that data. YOu would use filestream in exactly the same way, you would just end up doing a writeBytes() on each chunk of the file as it streams in.