couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Confused handling of HEAD requests
Date Thu, 21 Jul 2011 00:09:23 GMT
On Wed, Jul 20, 2011 at 6:32 PM, Randall Leeds <> wrote:
> On Wed, Jul 20, 2011 at 15:20, Paul Davis <> wrote:
>> On Wed, Jul 20, 2011 at 5:15 PM, Randall Leeds <> wrote:
>>> On Wed, Jul 20, 2011 at 15:09, Paul Davis <>
>>>> On Wed, Jul 20, 2011 at 5:03 PM, Travis Jensen <>
>>>>> 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
>>>>> that in start_response/3 and start_response_length/4 if your method is
>>>>> to HEAD.
>>>>> On the other hand, it sets all HEAD requests to GET, so no handler can
>>>>> 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
>>>>> would really like to know if it is HEAD or GET (generating the body takes
>>>>> 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
>>>>> -> 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.
>> 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.

View raw message