Ticket #3684 defect closed fixed
HEAD-handling code corrupts the HTTP channel in some cases, is generally redundant and confused in others
| Reported by: | glyph | Owned by: | washort |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | web | Keywords: | |
| Cc: | Branch: | branches/head-3684 | |
| Author: | washort | Launchpad Bug: |
Description
If an UnsupportedMethod exception is thrown for rendering a HEAD method, the default for Request.render (if GET is in allowedMethods) is to call render() again with the request mutated to have its method be GET. In some resources presumably this will return a body.
If the Resource's render_GET returns NOT_DONE_YET (i.e. defers writing its body to the channel), the body will actually be returned to the client, violating the RFC. If the method attribute were left as HEAD, then http.Request.write would enforce the no-data rule.
According to trial --coverage twisted.web, this code path is completely untested. It's not clear that it's even necessary, given that Resource.render_HEAD delegates to render_GET by default. (Or, vice versa.)
There's also more confused code at the end of server.Request.render that tries to specifically handle HEAD.
