Fix #6128 and #8150

[danbarua]

Request Type: bug

How to reproduce: it('should not double quote dates', function() {
$httpBackend.expect('GET', '/url?date=2014-07-15T17:30:00.000Z').respond('');
$http({url: '/url', params: {date:new Date('2014-07-15T17:30:00.000Z')}, method: 'GET'});
})

Currently, datetimes passed into $http.get params are wrapped in double quotes and then escaped giving urls like this: /url?date=%222014-07-15T17:30:00.000Z%22

Component(s): $http

Impact: large

Complexity: small

This issue is related to:

Detailed Description:

Other Comments:

See comments on #6128, #8150

[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 (#8154)

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!

[IgorMinar]

this is not right. toJSON doesn't have to return a string value, but we always need a string value, that's why we are doing this serialization.

how about we special case date instead? instead of your isDefined check on line 933 do isDate.

Are there other scenarios besides dates where toJSON doesn't do the right thing?

[danbarua]

Hi @IgorMinar , thanks for taking the time to review this PR.
As per my comments in issue #8150, I had initially taken the approach of special casing date as per below:

forEach(value, function(v) {
              if (v instanceof Date){
                  v = v.toISOString(); //toISOString() only supported in IE8 and above
              }
              else if (isObject(v)) {
                v = toJson(v);
              }
              parts.push(encodeUriQuery(key) + '=' +
                         encodeUriQuery(v));
            });

I then came across a similar older issue #6128 and I then thought that perhaps the .toJSON method would be a more robust approach.

Are there other scenarios besides dates where toJSON doesn't do the right thing?

I don't actually know of any scenarios, so I'd be happy to revert to the isDate approach.

[danbarua]

http://stackoverflow.com/questions/20734894/difference-between-tojson-and-json-stringify

That said, the main difference is that toJSON produces a value (a number, boolean, object, ...) that gets converted to a JSON string whereas JSON.stringify always produces a string.

It looks like special casing isDate is the correct approach - I'll submit a new commit.

[danbarua]

@IgorMinar It looks like special casing isDate is the correct approach - PR updated.

[IgorMinar]

landed. thanks