id,summary,reporter,owner,description,type,status,priority,milestone,component,resolution,keywords,cc,branch,branch_author,launchpad_bug
3684,"HEAD-handling code corrupts the HTTP channel in some cases, is generally redundant and confused in others",glyph,washort,"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.
",defect,closed,normal,,web,fixed,,,branches/head-3684,washort,
