Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com
 designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ_m3YBkkUg3L4HjOc411avdz_R2iacQuhrQeDvC3ALmEG5ROA@mail.gmail.com>
References: 
 <CAM37MUDiPhntFcyiYhZ=2adF-PDA=ucajNKqwKToN7m0jTy1nA@mail.gmail.com>
	<CAJ_m3YCN7nD9R+bqYZHk55pnb8n_1+KhxR8ZgO1vvdsGP90xdQ@mail.gmail.com>
	<CAAL6JQjg+qeR=w1o4dopZWwSY_8JtfxQO6zLe-0nL_ePuSLbQQ@mail.gmail.com>
	<CAJ_m3YBkkUg3L4HjOc411avdz_R2iacQuhrQeDvC3ALmEG5ROA@mail.gmail.com>
Date: Wed, 20 Jul 2011 16:32:27 -0700
Message-ID: 
 <CAAL6JQjiVjH2jmh93_tdj7apGSwGNv8ED3cL-MPk62K0SjARNw@mail.gmail.com>
Subject: Re: Confused handling of HEAD requests
From: Randall Leeds <randall.leeds@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 20, 2011 at 15:20, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> On Wed, Jul 20, 2011 at 5:15 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
>> On Wed, Jul 20, 2011 at 15:09, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>>> On Wed, Jul 20, 2011 at 5:03 PM, Travis Jensen <travis.jensen@gmail.com> 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 @ travis.jensen@gmail.com
>>>>
>>>> **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.
>>>
>>
>