couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Confused handling of HEAD requests
Date Wed, 20 Jul 2011 22:20:08 GMT
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.

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

Mime
View raw message