Fix Crawler::children() to not trigger a notice for childless node
merged branch lazyhammer/issue-8048 (PR #8054)

This PR was merged into the 2.1 branch.

Discussion
----------

[DomCrawler] Fix Crawler::children() to not trigger a notice for childless node

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #8048
| License       | MIT
| Doc PR        | n/a

Commits
-------

91b8490 Fix Crawler::children() to not trigger a notice for childless node
[CssSelector] Fix :nth-last-child() translation
[Console] fix and refactor exit code handling
merged branch lazyhammer/issue-8068-2.1 (PR #8073)

This PR was merged into the 2.1 branch.

Discussion
----------

[CssSelector] Fix :nth-last-child() translation

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #8068
| License       | MIT
| Doc PR        | n/a

Same as #8072, but for < 2.3

Commits
-------

1469953 [CssSelector] Fix :nth-last-child() translation
merged branch Tobion/console-exit-code (PR #8080)

This PR was merged into the 2.1 branch.

Discussion
----------

[Console] fix and refactor exit code handling

Split of #8038

Commits
-------

5c317b7 [Console] fix and refactor exit code handling
Fixed two bugs in HttpCache

1. 304 responses always send "Content-Type: text/html; charset=UTF-8"
header
I discovered that the HttpCache::handle method calls Response::prepare
after calling Response::isModified.  Response::isModified removes the
Content-Type header as it should, but Response::handle adds in the
default Content-Type header when none is set.  If the default
Content-Type is not the correct Content-Type, then the Content-Type in
the cache gets clobered.  I solved this problem by moving the
Response::isModified call after the Response::prepare call.  I updated
the testRespondsWith304WhenIfModifiedSinceMatchesLastModified and
testRespondsWith304WhenIfNoneMatchMatchesETag tests to verify that the
Content-Type header was not being sent for 304 responses.

2. Failure to invalidate cached entities referred to by the Location
header
I discovered that the Store::invalidate method was looking for Location
and Content-Location headers to invalidate, but it was looking in the
request headers instead of the response headers.  Because the
Store::invalidate method doesn't take a response, I decided it was
better to move this logic to the HttpCache::invalidate method instead.
I updated the testInvalidatesCachedResponsesOnPost test to verify that
Location headers are getting invalidated correctly.
merged branch jdesrosiers/ticket_8097 (PR #8098)

This PR was submitted for the 2.0 branch but it was merged into the 2.1 branch instead (closes #8098).

Discussion
----------

[HttpKernel] Fixed two bugs in HttpCache

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

1. 304 responses always send "Content-Type: text/html; charset=UTF-8"
header
I discovered that the HttpCache::handle method calls Response::prepare
after calling Response::isModified.  Response::isModified removes the
Content-Type header as it should, but Response::handle adds in the
default Content-Type header when none is set.  If the default
Content-Type is not the correct Content-Type, then the Content-Type in
the cache gets clobered.  I solved this problem by moving the
Response::isModified call after the Response::prepare call.  I updated
the testRespondsWith304WhenIfModifiedSinceMatchesLastModified and
testRespondsWith304WhenIfNoneMatchMatchesETag tests to verify that the
Content-Type header was not being sent for 304 responses.

2. Failure to invalidate cached entities referred to by the Location
header
I discovered that the Store::invalidate method was looking for Location
and Content-Location headers to invalidate, but it was looking in the
request headers instead of the response headers.  Because the
Store::invalidate method doesn't take a response, I decided it was
better to move this logic to the HttpCache::invalidate method instead.
I updated the testInvalidatesCachedResponsesOnPost test to verify that
Location headers are getting invalidated correctly.

Commits
-------

a4251bd [HttpKernel] Fixed two bugs in HttpCache