couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Confused handling of HEAD requests
Date Thu, 21 Jul 2011 09:32:42 GMT
Would any of this go away if we'd finally switched to Webmachine?

Cheers
Jan
-- 

On 21 Jul 2011, at 02:09, Paul Davis wrote:

> On Wed, Jul 20, 2011 at 6:32 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
>> 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.
>> 
> 
> 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.
>>>>> 
>>>> 
>>> 
>> 


Mime
View raw message