flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] Quick check on HttpService fix
Date Tue, 28 Feb 2017 23:48:50 GMT
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.dove@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 <aharui@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" <gregdove@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
>> >
>> >
>>
>>

Mime
View raw message