-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Add test for response headers #14074
Add test for response headers #14074
Conversation
@@ -0,0 +1,6 @@ | |||
def test_missing_first_match(new_session, add_browser_capabilities): | |||
response, _ = new_session({"capabilities": {"alwaysMatch": add_browser_capabilities({})}}) | |||
assert 'cache-control' in response.headers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you should lowercase the recieved values here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jgraham see PR question: shall we by default lowercase key and value pairs since headers are case insensitive?
@jgraham given the fact that this test should be applied to every response I moved the assertion into the |
I sort of feel we should return headers unmodified as they are presented to us, and only convert them to lowercase during assertion. |
There also appears to be some test failures after one of the recent fixups: |
@andreastt addressed outstanding issues |
Retriggered some of the jobs and dismissed @jgraham’s old review. |
Azure Pipeline is failing due to
continuous-integration/travis-ci/pr failing due to
|
@jgraham Aren’t those jobs supposed to run stability tests, like Travis? |
Yup, but only for tests that it recognizes as being somehow affected by the change set.
|
This library is used by the WPT infrastructure to run all the other conformance If we want to make this assertion for every WebDriver test, we could:
Although either would suffer from the problem above, just on a smaller scale. |
Or we could keep the checks in the client and emit a warning when the headers do not conform. I support the idea of moving the hard assertions to a separate test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment above.
@andreastt @jugglinmike I moved the assertions into the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea! Unlike the alternatives we've been considering, this may allow some responses to go untested. Those cases seem rare, so I think the simplicity of this approach wins out.
As for the timeout reported by Taskcluster: unlike with the previous solution, the system is now capable of identifying the affected tests:
2018-11-19 12:17:10,747 - tc-run - INFO - Identifying tests affected in range 'HEAD^'... 2018-11-19 12:17:26,483 - tc-run - INFO - Identified 138 affected tests
That's a lot of tests, possibly enough to exceed our 2-hour limit, though the logs for Chrome are suspiciously short...
The newly added assertion has failures:
@christian-bromann can you please fix that? Thanks |
f207ac2
to
641546e
Compare
@whimboo done
|
I don't know why it fails with Firefox given that we shipped the fix for |
Oh wait. The Firefox job with the patch applied doesn't fail! What's failing is the verify job, which is killed by taskcluster after a runtime of 7200s. |
@whimboo would closing and reopening the PR help? |
Not sure. Running all the tests simply take that long. Someone might take a bit of time to check how long those verify tasks run in general, and maybe we have to bump up the maximum allowed time. |
@whimboo I'm not sure we can while we're using the GitHub Taskcluster integration, but @jgraham would know better. There are a few cases where we end up running lots of tests, but I think the longer term plan is to do something smarter and dynamically shard them. In either case, if you think this looks good, we should just force-merge this. |
@jgraham I see WPT WebDriver tests failing in Chrome on Windows and Linux runs with this change, and pass after reverting it locally. Anyone else seeing this?
|
@mustjab I think that would be expected, since chromedriver doesn’t return the mandated See send a response in the spec. |
@andreastt So should we change the way we run these tests? We run them on a daily basis and at this moment most of the tests fail due to this error. |
Right, the assertion was added as a step to In order to avoid numerous workarounds, I think the best fix here is to insert a new line into https://cs.chromium.org/chromium/src/chrome/test/chromedriver/server/http_handler.cc?l=1125 and fix chromedriver. Alternatively we could back this change out temporarily to give you time to fix this. |
Thank you! I'll outreach to ChromeDriver team to fix this and for now, we'll run with this fix internally. |
I should have read the patch before merging it. I fully agree that this shouldn't be tested for every test but should be a specific set of tests or otherwise isolated from testing other features. |
@jgraham I will tweak the patch and make it so that it is handled in a single test instead of being part of all assertions. |
@jgraham, so we want to backout the already landed patch for a clean base? I don't think patching on top of the current patch is that great. |
If @mustjab is fixing chromedriver, I don’t necessarily see the need to move the assertion to separate test, nor a reason to back this out. |
The WebDriver spec defines the response header in the processing modal section as follows:
This patch adds tests for this case.
Question: the RFC defines header names as case insensitive. Should be lowercase header keys and values by default?
Note:: Geckodriver returns a wrong response value for content-type, so I created a bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1507428