On Wed, Jul 20, 2011 at 15:20, Paul Davis <[email protected]> wrote: > On Wed, Jul 20, 2011 at 5:15 PM, Randall Leeds <[email protected]> > wrote: >> On Wed, Jul 20, 2011 at 15:09, Paul Davis <[email protected]> >> wrote: >>> On Wed, Jul 20, 2011 at 5:03 PM, Travis Jensen <[email protected]> >>> wrote: >>>> couch_httpd.erl seems to be confused about what it wants to do with HEAD >>>> requests. >>>> >>>> On the one hand, it supports catching {http_head_abort, Resp} and will >>>> throw >>>> that in start_response/3 and start_response_length/4 if your method is set >>>> to HEAD. >>>> >>>> On the other hand, it sets all HEAD requests to GET, so no handler can ever >>>> know a HEAD request was made (instead, it lets Mochiweb strip the body). >>>> >>>> I can appreciate the simplicity of the latter, but >>>> the schizophrenic behavior seems odd. I've also got a custom handler that >>>> would really like to know if it is HEAD or GET (generating the body takes a >>>> lot of CPU, but I know its length because I store it in a document). >>>> >>>> First question: should Couch really set all HEAD requests to GET? >>>> (Personally, I think not) >>>> Second question: does anybody know how bad it would be to remove that HEAD >>>> -> GET mapping? >>>> >> >> It would be bad since a lot of the handlers specifically match against >> the method being GET. >> I have a ticket open to do smarter things with HEAD in general, >> especially as it relates to caching proxies and ETags: >> https://issues.apache.org/jira/browse/COUCHDB-941 >> >> It's something we should definitely set about fixing eventually, but I >> don't know what the priority is. >> >>>> Cheers. >>>> >>>> tj >>>> -- >>>> *Travis Jensen* >>>> *** >>>> *Read the Software Maven @ http://softwaremaven.innerbrane.com/ >>>> Read my LinkedIn profile @ http://www.linkedin.com/in/travisjensen >>>> Read my Twitter mumblings @ http://twitter.com/SoftwareMaven >>>> Send me email @ [email protected] >>>> >>>> **What kind of guy calls himself the Software Maven???** >>>> >>> >>> I don't have the answer at the tip of my fingers, but IIRC there was a >>> specific interaction that we had to do that so that something else >>> didn't break. I wonder if its possible to tag the request with a >>> special "is actually a HEAD request" thing so users can check. >> >> I don't like an "is actually a HEAD request" flag. >> Adding HEAD handlers is the right approach, but if we want to be lazy >> we could support a fallback to GET when we get a function_clause error >> trying to call the handler. >> > > Yeah, its definitely a hack. A fallback on function_clause would > definitely be much cleaner I think. Only thing is I tend to wonder if > there'd be a performance hit since our entire HTTP stack currently > relies on HEAD -> GET, which would be generate a lot of exception > handling.
It'd only occur when people do a HEAD request, so normal operation would be fine? Clearly we'd want to log a warning or something and start implementing all the HEAD responses properly. > >>> >>> I'd search through the dev@ list for chatter on that mapping around >>> the time it was made. I'm pretty sure there was a thread that we did >>> some discussion on that. >>> >> >
