Oh yeah, forgot about that. I thought this code worked at one point, maybe four or five years ago, but I was unable to find out when browsers started blocking it, so we can truly understand if it will never be needed again or will be needed on some older browser.
It could be the right answer is to have some sort of Trusted/UntrustedHTTPService choices for our customers. -Alex On 2/27/17, 8:37 PM, "Greg Dove" <gregd...@apache.org> wrote: >Justin logged a bug here and I encountered the same issue: >https://issues.apache.org/jira/browse/FLEX-35271 > >At first glance this seems like a real quick fix, just delete the two >lines from : > >if (contentData) { > element.setRequestHeader('Content-length', >contentData.length.toString()); > element.setRequestHeader('Connection', 'close'); > element.send(contentData); >} else { > element.send(); > } > >changing to: > >if (contentData) { > element.send(contentData); >} else { > element.send(); > } > >or possibly even something like: >element.send(contentData || ""); > > >I just thought I would double-check if anyone knew why these headers were >included originally. Even if it was permitted (it seems clear that it is >not), I don't think that content-length would always be correct byte >count in the above case if the string was utf8...because the string >length can be different to its byte length. > >If I hear nothing or if there are no objections, I will make the change >above. > >regards, >Greg > >
