I thought that the purpose of HEAD was to tell whether a resource had changed, and that it had effectively been made obsolete by If-Modified-Since and Etag. I suppose you could use HEAD to see if the resource exists or you have permission to view it, but I don't know of anybody that does that. In any case, these uses do not depend on Content-Length. The only use of prechecking Content-Length is, um, to see how large the response is?
So i think very few people have thought about HEAD in the past fifteen years, and those that do probably just return None in the action. If we change it, we may as well do it in the right place. According to Graham's article, that would be in the top-level WSGI server. So we can maybe get Ian to modify Paste, but we can't necessarily get everybody to change their servers. HEAD seems like a subset of GET as far as permissions go, so I'd support letting Routes implicitly treat HEAD like GET. @restrict is another question, but if there's no way to exploit HEAD and it's really a variation of GET, then it might be OK. Perhaps HTTP should have defined a separate header for this (Return-body: no) rather than making it an HTTP action. If we change HEAD to GET, we should probably add a flag in the WSGI environment that we did so. Because applications might want to avoid doing large database retrievals in that case, even if it messes up the Content-length header. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
