On Jul 21, 2011 2:33 AM, "Jan Lehnardt" <[email protected]> wrote: > > Would any of this go away if we'd finally switched to Webmachine?
All of it. > > Cheers > Jan > -- > > On 21 Jul 2011, at 02:09, Paul Davis wrote: > > > On Wed, Jul 20, 2011 at 6:32 PM, Randall Leeds <[email protected]> wrote: > >> 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. > >> > > > > Though I think some libraries will use HEAD requests to check if they > > can short circuit some operations. No idea what sort of density that'd > > be and it'd obviously be fairly lib/usecase specific. > > > > Also true, if we change this, adding real HEAD responses would be > > useful. Granted in a webmachine world this would all Just Work. > > > >>> > >>>>> > >>>>> 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. > >>>>> > >>>> > >>> > >> >
