Repository: angular
Issue: Headers.{Constructor,append,set} with Date value should use correct format
Labels: freq2: medium,area: common/http,type: use-case,P4

<!--
PLEASE HELP US PROCESS GITHUB ISSUES FASTER BY PROVIDING THE FOLLOWING INFORMATION.

ISSUES MISSING IMPORTANT INFORMATION MAY BE CLOSED WITHOUT INVESTIGATION.
-->

## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

## Current behavior
`Date` objects added to `Headers` get turned into strings with a non-standard format.

## Expected behavior
`Date` objects added to `Headers` get turned into strings with the standard (i.e., HTTP-date) format as specified in [RFC 7231 Section 7.1.1.1](https://tools.ietf.org/html/rfc7231#section-7.1.1.1).

I expect this behavior, and use "should" in the issue title, because of my first point in the "What is the motivation / use case for changing the behavior?" section.

## Minimal reproduction of the problem with instructions
<!--
For bug reports please provide the *STEPS TO REPRODUCE* and if possible a *MINIMAL DEMO* of the problem via
https://plnkr.co or similar (you can use this template as a starting point: http://plnkr.co/edit/tpl:AvJOMERrnz94ekVua0u5).
-->
http://plnkr.co/edit/mzixw2aYhMwUlJvWcZeQ

## What is the motivation / use case for changing the behavior?
* I believe the following sentence (from RFC 7231 Section 7.1.1.1) applies to Angular.
>                                                  When a sender generates a
>        header field that contains one or more timestamps defined as
>        HTTP-date, the sender MUST generate those timestamps in the
>        IMF-fixdate format.
Specifically I believe Angular is (or, at least, can be used as) a "sender" in the sense of that sentence. (I know that strict adherence to a spec is not a strong argument.)
* I think this is a bug, instead of a feature request, because of the use of "MUST" in that sentence.
* Angular could make writing a hypertext (dare I say "REST") API client easier by not requiring an author of each such client to implement this (required of the standard) functionality.

### Rationale (i.e., why should this be an Angular change)
First: I do not know if Angular is the right place to raise this issue. The other places I think this issue could be addressed are Fetch and TC39 (ECMAScript).

I think Angular is doing as much as can be inferred from [Fetch](https://fetch.spec.whatwg.org/). As [the `Headers` "class" is defined in Fetch](https://fetch.spec.whatwg.org/#headers-class), this _could_ be (though since Fetch only cares about `ByteString` I feel it is currently unlikely to be) a change that could fit Fetch. Even if this did apply to Fetch, it would still need to be _implemented_ here.

Also, based on the current `Date\.prototype\.to.*String` functions defined in ECMA-262, I do not think that this could be addressed by TC39 (though I haven't asked). Specifically because the relevant sections (20.3.4.{35, 36, 37, 38, 39, 40, 41.1, 42, 43}) of ECMA-262 specify the format of the String return value of every such function to be "implementation-dependent", adding a new one (perhaps named `Date.prototype.toHTTPDateString`) without that "it's up to you" flavor seems out of place. Again, even if such a function is added to `Date.prototype`, Angular would need to change to use it.

So, no matter what, I think some work needs to be done to here.

## Environment

I think all this is irrelevant.

<pre><code>
Angular version: "latest", per the Plunk
<!-- Check whether this is still an issue in the most recent Angular version -->

Browser:
- [x] Chrome (desktop) version XX
- [x] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [x] Firefox version 55.0.3
- [x] Firefox (Android) version 55.0.2
- [ ] Safari (desktop) version XX
- [x] Safari (iOS) version XX
- [x] IE version 11
- [x] Edge version 40.15063.0.0 (EdgeHTML 15.15063)
 
For Tooling issues:
- Node version: 6.9.5  <!-- run `node --version` -->
- Platform:  checked with the indicated browsers on Windows, Android, and iOS

Others:
<!-- Anything else relevant?  Operating system version, IDE, package manager, HTTP server, ... -->
</code></pre>