This PR was squashed before being merged into the 2.8 branch (closes #22036).

Discussion
----------

Set Date header in Response constructor already

| Q             | A
| ------------- | ---
| Branch?       | 2.8
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets |
| License       | MIT
| Doc PR        |

Setting the `Date` header in the `Response` constructor has been removed in #14912 and changed to a more lazy approach in `getDate()`.

That way, methods like `getAge()`, `getTtl()` or `isFresh()` cause side effects as they eventually call `getDate()` and the Request "starts to age" once you call them.

I don't know if this would be a nice test, but current behaviour is

```php
        $response = new Response();
        $response->setSharedMaxAge(10);
        sleep(20);
        $this->assertTrue($response->isFresh());
        sleep(5);
        $this->assertTrue($response->isFresh());
        sleep(5);
        $this->assertFalse($response->isFresh());
```

A particular weird case is the `isCacheable()` method, because it calls `isFresh()` only under certain conditions, like particular status codes, no `ETag` present etc. This symptom is also described under "Cause of the problem" in #19390, however the problem is worked around there in other ways.

So, this PR suggests to effectively revert #14912.

Additionally, I'd like to suggest to move this special handling of the `Date` header into the `ResponseHeaderBag`. If the `ResponseHeaderBag` guards that we always have the `Date`, we would not need special logic in `sendHeaders()` and could also take care of #14912 (comment).

Commits
-------

3a7fa7e Set Date header in Response constructor already

…pdonadio)

This PR was squashed before being merged into the 3.2 branch (closes #22304).

Discussion
----------

Moved $this->setDate() before the deprecation handling.

| Q             | A
| ------------- | ---
| Branch?       | 3.2 <!-- see comment below -->
| Bug fix?      | yes
| New feature?  | no <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks?    | no?
| Deprecations? | no <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass?   | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!--highly recommended for new features-->

<!--
- Bug fixes must be submitted against the lowest branch where they apply
  (lowest branches are regularly merged to upper ones so they get the fixes too).
- Features and deprecations must be submitted against the master branch.
- Please fill in this template according to the PR you're about to submit.
- Replace this comment by a description of what your PR is solving.
-->

#22036 merged the patch into the wrong place; the `$this->setDate()` happens after the deprecation handling, so it does not always get called.

See also https://www.drupal.org/node/2712647?page=1#comment-12025349

Commits
-------

b6df4e7 Moved ->setDate() before the deprecation handling.

…pdonadio)

This PR was squashed before being merged into the 3.2 branch (closes #22304).

Discussion
----------

Moved $this->setDate() before the deprecation handling.

| Q             | A
| ------------- | ---
| Branch?       | 3.2 <!-- see comment below -->
| Bug fix?      | yes
| New feature?  | no <!-- don't forget updating src/**/CHANGELOG.md files -->
| BC breaks?    | no?
| Deprecations? | no <!-- don't forget updating UPGRADE-*.md files -->
| Tests pass?   | yes
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!--highly recommended for new features-->

<!--
- Bug fixes must be submitted against the lowest branch where they apply
  (lowest branches are regularly merged to upper ones so they get the fixes too).
- Features and deprecations must be submitted against the master branch.
- Please fill in this template according to the PR you're about to submit.
- Replace this comment by a description of what your PR is solving.
-->

symfony/symfony#22036 merged the patch into the wrong place; the `$this->setDate()` happens after the deprecation handling, so it does not always get called.

See also https://www.drupal.org/node/2712647?page=1#comment-12025349

Commits
-------

b6df4e7 Moved ->setDate() before the deprecation handling.

…seHeaderBag (mpdude)

This PR was squashed before being merged into the 3.4 branch (closes #22124).

Discussion
----------

Shift responsibility for keeping Date header to ResponseHeaderBag

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets |
| License       | MIT
| Doc PR        |

This is an improvement over #22036. It shifts responsibility for preserving a `Date` header to the `ResponseHeaderBag`.

We already have similar logic there for the `Cache-Control` header.

Commits
-------

5d83836 Shift responsibility for keeping Date header to ResponseHeaderBag