Skip to content
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

MUST NOT send Transfer-Encoding or Content-Length for 1xx or 204 #166

Merged
merged 2 commits into from Sep 1, 2018

Conversation

alexanderlukanin13
Copy link
Contributor

Fixes #165

@digitalresistor
Copy link
Member

Also fixes/closes: #152

@mmerickel
Copy link
Member

This fix does not affect the content-length at all so I think #152 is still valid but probably needs to be fixed in webob, not waitress.

@digitalresistor
Copy link
Member

Do we have a test that will verify waitress will not send any content even if the WSGI app returns a body for the 204 and that we still close the iterator correctly (even if we don't iterate over it)?

@digitalresistor
Copy link
Member

You may be correct @mmerickel. Need to verify.

@@ -202,6 +202,23 @@ def test_build_response_header_v11_200_no_content_length(self):
self.assertEqual(inst.close_on_finish, True)
self.assertTrue(('Connection', 'close') in inst.response_headers)

Copy link
Member

Choose a reason for hiding this comment

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

Also needs a test for a 10x status.

Copy link
Member

Choose a reason for hiding this comment

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

There is a test for if the status code starts with 1.

Copy link
Member

Choose a reason for hiding this comment

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

@bertjwregeer I'm talking about branch coverage: the PR does not add a new testcase for the 10x status code, only for 204. It also doesn't update any existing testcases which might have triggered the same branch.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@tseaver @bertjwregeer Added test for HTTP 1xx (specifically 100 Continue) code. Test is the same as for 204. If you want more in-depth testing, please ask someone with a good knowledge of waitress.

# RFC 7230: MUST NOT send Transfer-Encoding or Content-Length
# for any response with a status code of 1xx or 204.
if not (self.status.startswith('1') or
self.status.startswith('204')):
Copy link
Member

Choose a reason for hiding this comment

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

I would be included to factor the test into a self.no_body() method, and then test that for the different status codes.

@digitalresistor
Copy link
Member

@mmerickel That's not an issue in WebOb.

The issue is related to how Waitress deals with responses that don't contain a Content-Length header:

def test_execute_app_returns_204_no_content_without_cl(self):
        def app(environ, start_response):
            start_response('204 No Content', [])
            return [b'']

        inst = self._makeOne()
        inst.channel.server.application = app
        inst.execute()
        self.assertEqual(inst.content_length, None)
======================================================================
FAIL: test_execute_app_returns_204_no_content_without_cl (waitress.tests.test_task.TestWSGITask)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/xistence/Projects/waitress/waitress/tests/test_task.py", line 486, in test_execute_app_returns_204_no_content_without_cl
    self.assertEqual(inst.content_length, None)
AssertionError: 0 != None

@digitalresistor
Copy link
Member

@alexanderlukanin13 do you have time to incorporate the changes that @tseaver requested?

@digitalresistor
Copy link
Member

Thank you @alexanderlukanin13, I'll try and get some work done on this tonight!

@digitalresistor
Copy link
Member

Please see #202 for a follow-up to this PR that includes a fix for the 304 issue and goes a step further to make sure we don't accidentally send a further response than expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants