Closed Bug 1496754 Opened Last year Closed Last year
Can't create new AWS Lambda function
Steps to reproduce: 1. go to the AWS Lambda console 2. press "create function" 3. give it a name, and choose any role 4. press the "Create function" Expected: The function is created and the page navigations to the function configuration. Actual: The button stays greyed out for a while, then eventually returns to its original state and no navigation occurs. The function is not created. mozregression points at bug 1454325 as the cause of the regression. [Tracking Requested - why for this release]: This significantly impacts the ability to use a feature of AWS in Firefox.
Anne, what do you think? I get the feeling that between this and the Mapbox issue in bug 1494443, we need to at least make the pref added in bug 1454325 nightly-only for now (if even nightly-only), while we work the details out with site owners and other browser vendors.
What's the specific problem here? Does AWS want to see a space between the semicolon and the following parameter? Is there a rationale better than minification for the serialization algorithm in the spec not putting a space there?
Yeah, it'd be good to know the specific problem here. I basically see two solutions: 1. We start serializing with a space. 2. We only modify the existing Content-Type header if the charset parameter value is not a case-insensitive (or case-sensitive as other browsers do modify otherwise, but they also modify in place and not parse-then-serialize) match for UTF-8. I filed https://github.com/whatwg/mimesniff/issues/84 to coordinate with other implementers who are also in the process of tackling this.
Do we have any test account credentials that I could use to sign into AWS? (And if we do, will there be a two-factor ping requiring some coordination?)
Just to update, we're asking our friends at Amazon about creds.
(In reply to Thomas Wisniewski [:twisniewski] from comment #4) > Do we have any test account credentials that I could use to sign into AWS? > (And if we do, will there be a two-factor ping requiring some coordination?) You could sign up for a free account, I think: https://aws.amazon.com/free/
I'm waiting on a test-account in bug 1498268, but if that drags on too much longer I'll just bite the bullet and provide AWS with my phone number to make a free account.
(That said, we're also reverting the change that causes this in bug 1499136, so the need for this is diminished).
Anne, I finally got my test-account to confirm what's happening here. The problem here is the case-normalization, not a missing space. We're sending this: >application/json;charset=UTF-8 But if I disable dom.xhr.standard_content_type_normalization in about:config, we send this, and the AWS Lambda function is successfully created: >application/json;charset=utf-8
Thanks a lot Thomas, that means https://github.com/whatwg/xhr/pull/224 fixes it (as we'll just leave the Content-Type header alone). No site so far suggests that serializing the MIME type with a space is also needed, but that's probably still what we should do I think. Hmm.
I can confirm this is working now in 65.0a1.
Marion, I think this should actually be fixed in 64, since it was fixed in bug 1499136 (which is marked as fixed in 64).
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Assignee: nobody → twisniewski
Depends on: 1499136
Target Milestone: --- → mozilla64
You need to log in before you can comment on or make changes to this bug.