adds xhrFields to $http config object

[sjurba]

The properties of the xhrFields object is set on the XHR object making it possible to set non-standard properties. It is also possible to set the object on $http.defaults to use it globally. Please note that this will not work for certain non-standard read-only properties specified by Mozilla, such as mosSystem and mozAnon as they must be passed throught the constructor.

[mary-poppins]

Thanks for the PR! Please check the items below to help us merge this faster. See the contributing docs for more information.

• Uses the issue template (#8160)

If you need to make changes to your pull request, you can update the commit with git commit --amend.
Then, update the pull request with git push -f.

Thanks again for your help!

[caitp]

"should pass xhrFields params" ... to what?

[sjurba]

to $httpBackend.. But I was just following the lead of the 2 tests above..
Want me to update?

[sjurba]

Fixed the test title and removed left-over parameter in createXhr.

[jeffbcross]

I'm typically against the idea of proxying underlying mechanisms through the higher level APIs. Doing so opens a pandora's box of potential bugs. If there is a feature provided by underlying mechanism (XHR) that could be useful to $http (or any other service), it should either be supported in the service directly or made into a completely separate service if it doesn't belong in the original.

Others on the team may disagree :)

@caitp what are your thoughts?

[caitp]

Based on jQuery's implementation, I don't have a huge problem with exposing aw ay to do this.

[pkozlowski-opensource]

@sjurba out of curiosity - what is the practical use-case you've got for this change? I'm aware of the FFoxOS-specific args that we need to pass to the XHR's constructor but I wonder what are the non-standard properties that you've bumped into.

I'm leaning towards proposing a more generic solution where there would be a dedicated service responsible for creating XHR instances but yeh, would like to understand all the use-cases first.

[sjurba]

It's just the Firefox os params we've encountered really. In our specific case we ended up resolving it with implementing the proper CORS headers server side... 

—
Sjur

On Sun, Dec 14, 2014 at 1:22 PM, Pawel Kozlowski [email protected]
wrote:

@sjurba out of curiosity - what is the practical use-case you've got for this change? I'm aware of the FFoxOS-specific args that we need to pass to the XHR's constructor but I wonder what are the non-standard properties that you've bumped into.

I'm leaning towards proposing a more generic solution where there would be a dedicated service responsible for creating XHR instances but yeh, would like to understand all the use-cases first.

Reply to this email directly or view it on GitHub:
#8160 (comment)

[googlebot]

Thanks for your pull request.

It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at https://cla.developers.google.com/.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check the information on your CLA or see this help article on setting the email on your git commits.

Once you've done that, please reply here to let us know. If you signed the CLA as a corporation, please let us know the company's name.

[caitp]

So, I've been talking with @petebacondarwin about a new approach for getting changes like this into the library, and this might be a good candidate.

Still waiting for a few other team members to give their inputs on whether it's a good idea or not, but what I want to do is get feedback from the community (and other core team members) on changes like this, so that we can try and steer the framework in a good direction.

Things we want to figure out:

1. How many users need this
2. How inconvenient is it to not support this
3. What is the simplest and most powerful way to expose the facilities needed

My view is that we should probably enable applications to control how XHR is instantiated, and let them do that during config time. But maybe an API design like that would suck, or maybe the complexity of adding this is not worth it for the number of users that need it. Or maybe it is, we really need feedback from developers to figure this out.

I think it would be worth putting together a document with a detailed plan (and maybe some alternatives) to seed discussion in the community so that we can make the right decision with this.

I'll provide a bit more info if I get feedback on this idea, so leaving this open for now

[sjurba]

I'll try pitch in my 2 cents on this.

Our need originated from the need to disable CORS restrictions in Firefox OS app Development. In Firefox OS all apps are webapps and are restricted by the browsers normal CORS restrictions. In an packaged (installed) app, the format of the origin url is app://your.domain, which means that any ajax calls in your code will trigger the CORS restrictions. The proper solution to this is to implement the correct CORS headers server side. If that is not the option, this is where the mozSystem workaround comes to play, as it will disable the CORS restrictions.

1. How many users need this?
   • Anyone writing an Firefox OS app that does not control the server side headers.
     • Running on cloud service
     • Getting data from someone else's service (Eg. News aggregations etc)
     • Debugging/Prototyping

2.How inconvenient is it to not support this?
Users would need to implement AJAX requests without using $http.

3.What is the simplest and most powerful way to expose the facilities needed?
I agree that a way to control XHR is instantiated at config time would be good.

A separate benefit might be that it could be very useful for simplyfying mocking and testing of the $http service.

[googlebot]

CLAs look good, thanks!

[Narretz]

@pkozlowski-opensource You said you want to look into this later, right? I'll tentatively assign you for it.

[pkozlowski-opensource]

Yes, I will take care of this one, thnx @Narretz

[Narretz]

This was implemented differently in #12159