couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <>
Subject Re: Confused handling of HEAD requests
Date Wed, 20 Jul 2011 22:15:32 GMT
On Wed, Jul 20, 2011 at 15:09, Paul Davis <> wrote:
> On Wed, Jul 20, 2011 at 5:03 PM, Travis Jensen <> 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:

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 @
>> Read my LinkedIn profile @
>> Read my Twitter mumblings @
>> Send me email @
>> **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.

> 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.

View raw message