OK, sounds good. 2009 plus a few years for browsers I use to catch up sounds about the right timing to me.
-Alex On 2/28/17, 2:21 PM, "Greg Dove" <greg.d...@gmail.com> wrote: >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-setrequesthead >er-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 >> > >> > >> >>
