I'm not sure I agree--if it's a "feature" of the implementation that prevents valid use of the API, that sounds like a bug ;). As far as I can tell, a null byte should be encoded to %00 in the application/x-form-urlencoded scheme and is a valid character. If calling toString() on a ByteArray truncates it, then the implementation shouldn't be doing that. String does seem to handle null bytes correctly in other cases (try trace(String.fromCharCode(1,0,2).length) ), so there should be no problem here.
Also: > It does work correctly if you set URLRequest.data to a ByteArray Not in Linux Flash Player--that was my original point. Thanks for the feedback, though--it's always interesting to dive into this low-level stuff. -- Maciek Sakrejda Truviso, Inc. http://www.truviso.com -----Original Message----- From: Troy Gilbert <[EMAIL PROTECTED]> Reply-To: flexcoders@yahoogroups.com To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] URLRequest, ByteArray, and the 0 byte Date: Tue, 30 Sep 2008 11:57:09 -0500 > Ah, interesting. This seems related, but different. I was just setting > URLRequest.data to a ByteArray directly. In your case, if I understand > application/x-www-form-urlencoded correctly, then zero bytes should just > be replaced with %00. Have you filed a bug? I'd like to add that to my > Adobe JIRA watch list if so. It does work correctly if you set URLRequest.data to a ByteArray, but in my example I was setting URLVariables.data (which could be called anything, it's just a named property) to a ByteArray, and URLVariables (apparently) calls toString on each property's value *before* URL-encoding them, which is the problem. So, not necessarily a bug, just an undocumented "feature" of the implementation. Since URLVariables does the encoding, I expected/assumed (since it wasn't explicitly documented) it would it encode the ByteArray as bytes, %00 and all. Troy.
