Skip to content

Shift responsibility for keeping Date header to ResponseHeaderBag #22124

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

Shift responsibility for keeping Date header to ResponseHeaderBag #22124

wants to merge 2 commits into from

Conversation

mpdude
Copy link
Contributor

@mpdude mpdude commented Mar 23, 2017

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.

@fabpot
Copy link
Member

fabpot commented Mar 23, 2017

I would do that in master as there is no bug fix here.

@mpdude
Copy link
Contributor Author

mpdude commented Mar 23, 2017

@fabpot Fine for me. Can you do this when merging, or do you need a new PR?

@fabpot
Copy link
Member

fabpot commented Mar 23, 2017

You can change the target branch on the PR directly.

@mpdude mpdude changed the base branch from 2.8 to master March 23, 2017 17:01
@mpdude
Copy link
Contributor Author

mpdude commented Mar 23, 2017

Must be a new GH feature or it has always been so well hidden I missed it.

Changed.

),
array(
array('ETag' => 'xyzzy'),
array('ETag' => array('xyzzy'), 'Cache-Control' => array('private, must-revalidate')),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im not sure you can simply remove the cache-control expectations, perhaps re-add it in a separate test. Which is probably best in the long run.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I am not mistaken, there are other tests for them. In this test method that was only noise AFAICT, but please correct me if I'm wrong

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right 👍 same situation is covered in testCacheControlHeader

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@nicolas-grekas nicolas-grekas added this to the 3.3 milestone Mar 24, 2017
@fabpot fabpot modified the milestones: 3.4, 3.3 Apr 26, 2017
Copy link
Member

@fabpot fabpot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you rebase before I merge to get rid of the merge commits? Thanks.

@fabpot
Copy link
Member

fabpot commented Jun 16, 2017

If you could also change the target to 3.4, that would be wonderful.

@mpdude mpdude changed the base branch from master to 3.4 June 16, 2017 18:10
@mpdude
Copy link
Contributor Author

mpdude commented Jun 16, 2017

@fabpot changed base to 3.4 – did I get you right?

Also, at least in the web interface, GitHub shows no merge conflicts...?

@fabpot
Copy link
Member

fabpot commented Jun 16, 2017

3.4 👍
Can you still rebase please? We don't merge PRs with merge commits.

@mpdude
Copy link
Contributor Author

mpdude commented Jun 16, 2017

Hm, rebasing and fixing up a branch that I had previously rebased in the GH web interface, including merge conflicts, really challenged my git skills... hope it's allright now.

@fabpot
Copy link
Member

fabpot commented Jun 16, 2017

Apparently, tests are broken on deps low.

The headers returned now also include the "Date", but adding it to the expected outcome would add additional noise.

So instead I chose to test that only the given headers would remain present, preserving case.

The Cache-Control was not important here, we have other tests covering that aspect.
@mpdude
Copy link
Contributor Author

mpdude commented Jun 16, 2017

Messed up the test during merge conflict resolution, should be fixed now.

@fabpot
Copy link
Member

fabpot commented Jun 16, 2017

Thank you @mpdude.

fabpot added a commit that referenced this pull request Jun 16, 2017
…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
@fabpot fabpot closed this Jun 16, 2017
@mpdude mpdude deleted the guard-date-in-headerbag branch June 16, 2017 21:43
This was referenced Oct 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants