This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: http tests testing more than the error code are fragile
Type: Stage: resolved
Components: Library (Lib), Tests Versions: Python 3.3
Status: closed Resolution: duplicate
Dependencies: Superseder: http.server.BaseHTTPRequestHandler.send_error , ability send a detailed response
View: 12921
Assigned To: Nosy List: karlcow, orsenthil, r.david.murray
Priority: normal Keywords:

Created on 2013-03-05 12:21 by karlcow, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (2)
msg183521 - (view) Author: karl (karlcow) * Date: 2013-03-05 12:21
Some of the tests of the HTTP Test suite are checking for the full status-line, instead of just the error code.

Why is it an issue?

1. The only mandatory part in the status-line is the error code. The phrase is optional. For example the response is made of 3 parts.

   HTTP/1.1 400 Bad Request
   ('HTTP/1.1', '400', 'Bad Request')

Only 400 is the mandatory part of the error code and is testing the error.

2. It creates dependencies on how we conceive, modify the construction of the status-line and error messages.

3. Some tests are testing messages with different "optional texts".
Test for "HTTP/1.1 400 Line Too Long\r\n".
Instead of just testing "400". (A specific message could be put in the body, but that's informational)
Test for "HTTP/1.1 414 Request-URI Too Long\r\n"
instead of just testing "414", btw the spec says for the optional message "URI Too Long"

Testing the message, IMHO, should be only, for testing the construction of the message. The tests here are made for testing the right error code, but they try to do more.

Hope it helps :)

Threading: related to
msg183526 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-03-05 13:35
We are testing our http server.  It is not obviously inappropriate to test the full string.  Especially in the Line to Long case, where we are testing that our specific error message is produced.  If you wish to argue that we should emit the standard message and only put the specific info in the body of the response, that would be a design change, and then we should probably test for *that*, since it would be a change from current behavior.  Personally I find the more-specific information being in the response code message to be helpful, but I haven't done enough web programming lately for my opinion to count for much :)

So, I do not think this issue needs to be separate from issue 12921.  The tests should be fixed as part of the enhancement being advocated there (and I certainly agree it should be *possible* to control the two messages separately, regardless of what we choose to do by default).
Date User Action Args
2022-04-11 14:57:42adminsetgithub: 61557
2013-03-05 13:35:23r.david.murraysetstatus: open -> closed

superseder: http.server.BaseHTTPRequestHandler.send_error , ability send a detailed response

nosy: + r.david.murray
messages: + msg183526
resolution: duplicate
stage: resolved
2013-03-05 12:21:46karlcowsetcomponents: + Library (Lib), Tests
2013-03-05 12:21:27karlcowcreate