Thanks Alex, At this point I assume that removing these headers does not relate to 'Trusted'/ 'Untrusted', so I will remove them as it appears to me to be currently broken. These are currently not permitted [1] As near as I can tell it has been not permitted since at least 2009 specs [2] I may be overly optimistic but I'm assuming that all the current browsers are now compliant (Edge and Chrome on windows are for sure, I can see them adding content-length, but not the connection header).
Increasingly there is a move to forcing use of https/TLS (e.g. iOS apps) - is that what you mean by 'trusted'? I wasn't really clear in terms of understanding that part. 1.https://fetch.spec.whatwg.org/#forbidden-header-name 2. https://www.w3.org/TR/2009/WD-XMLHttpRequest2-20090820/#the-setrequestheader-method On Tue, Feb 28, 2017 at 7:20 PM, Alex Harui <aha...@adobe.com> wrote: > 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 > > > > > >
