You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Travis Jensen <tr...@gmail.com> on 2011/07/21 00:03:15 UTC
Confused handling of HEAD requests
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?
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???**
Re: Confused handling of HEAD requests
Posted by Travis Jensen <tr...@gmail.com>.
On Wed, Jul 20, 2011 at 10:36 PM, Travis Jensen <tr...@gmail.com>wrote:
>
> I'll dig into the archives and see if I can find the previous discussion on
> the topic. I might have to put an uber-ugly hack in for my use in the
> meantime. I don't mind spending time doing the "right" thing as long as I
> know what the "right" thing is.
>
I dug into the source archive to find out when the mapping happened. March,
2008, when Mochiweb was incorporated (or updated or something). The third
issue in Jira was HEAD not being supported and was resolved as part of that
checkin. No other communications about this specific topic appear to exist.
Unfortunately, that would imply it wasn't a "fix" for something else, but
rather "the way CouchDB will handle HEAD".
Now to decide how to deal with this for my project...
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???**
Re: Confused handling of HEAD requests
Posted by Travis Jensen <tr...@gmail.com>.
On Wed, Jul 20, 2011 at 4:15 PM, Randall Leeds <ra...@gmail.com>wrote:
>
> 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.
>
>
Unfortunately, that won't work. Most handlers have a clause that looks like
this:
db_req(#httpd{path_parts=[_DbName]}=Req, _Db) ->
send_method_not_allowed(Req, "DELETE,GET,HEAD,POST");
that will catch that inappropriate HEAD request. I guess
send_method_not_allowed/2 could be modified to test if HEAD is in the list
and throw an error.
I'll dig into the archives and see if I can find the previous discussion on
the topic. I might have to put an uber-ugly hack in for my use in the
meantime. I don't mind spending time doing the "right" thing as long as I
know what the "right" thing is.
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???**
Re: Confused handling of HEAD requests
Posted by Paul Davis <pa...@gmail.com>.
On Thu, Jul 21, 2011 at 1:01 PM, Travis Jensen <tr...@gmail.com> wrote:
> So is there anything I can do to help solve this "right" or should I just
> put my hack in place for now and call it good for the time being?
>
> tj
>
We like to refer to it as "organically grown." :D
But in seriousness, the fix for this weirdness will probably take
quite a bit of effort which means it'll be awhile. I'd stick to the
hack for now and then when we get a better HTTP layer built up it
should obviate the need for it.
> On Thu, Jul 21, 2011 at 11:38 AM, Benoit Chesneau <bc...@gmail.com>wrote:
>
>> On Thu, Jul 21, 2011 at 7:05 PM, Randall Leeds <ra...@gmail.com>
>> wrote:
>> > On Jul 21, 2011 2:33 AM, "Jan Lehnardt" <ja...@apache.org> wrote:
>> >>
>> >> Would any of this go away if we'd finally switched to Webmachine?
>> >
>> > All of it.
>> >
>> Though there are other problems like range handling and such things. I
>> think HEAD could also work if we stop throwing and instead check
>> states.
>>
>> - benoit
>>
>
>
>
> --
> *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???**
>
Re: Confused handling of HEAD requests
Posted by Travis Jensen <tr...@gmail.com>.
So is there anything I can do to help solve this "right" or should I just
put my hack in place for now and call it good for the time being?
tj
On Thu, Jul 21, 2011 at 11:38 AM, Benoit Chesneau <bc...@gmail.com>wrote:
> On Thu, Jul 21, 2011 at 7:05 PM, Randall Leeds <ra...@gmail.com>
> wrote:
> > On Jul 21, 2011 2:33 AM, "Jan Lehnardt" <ja...@apache.org> wrote:
> >>
> >> Would any of this go away if we'd finally switched to Webmachine?
> >
> > All of it.
> >
> Though there are other problems like range handling and such things. I
> think HEAD could also work if we stop throwing and instead check
> states.
>
> - benoit
>
--
*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???**
Re: Confused handling of HEAD requests
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Jul 21, 2011 at 7:05 PM, Randall Leeds <ra...@gmail.com> wrote:
> On Jul 21, 2011 2:33 AM, "Jan Lehnardt" <ja...@apache.org> wrote:
>>
>> Would any of this go away if we'd finally switched to Webmachine?
>
> All of it.
>
Though there are other problems like range handling and such things. I
think HEAD could also work if we stop throwing and instead check
states.
- benoit
Re: Confused handling of HEAD requests
Posted by Randall Leeds <ra...@gmail.com>.
On Jul 21, 2011 2:33 AM, "Jan Lehnardt" <ja...@apache.org> wrote:
>
> Would any of this go away if we'd finally switched to Webmachine?
All of it.
>
> Cheers
> Jan
> --
>
> On 21 Jul 2011, at 02:09, Paul Davis wrote:
>
> > On Wed, Jul 20, 2011 at 6:32 PM, Randall Leeds <ra...@gmail.com>
wrote:
> >> On Wed, Jul 20, 2011 at 15:20, Paul Davis <pa...@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.
> >>>>>
> >>>>
> >>>
> >>
>
Re: Confused handling of HEAD requests
Posted by Jan Lehnardt <ja...@apache.org>.
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 <ra...@gmail.com> wrote:
>> On Wed, Jul 20, 2011 at 15:20, Paul Davis <pa...@gmail.com> wrote:
>>> On Wed, Jul 20, 2011 at 5:15 PM, Randall Leeds <ra...@gmail.com> wrote:
>>>> On Wed, Jul 20, 2011 at 15:09, Paul Davis <pa...@gmail.com> wrote:
>>>>> On Wed, Jul 20, 2011 at 5:03 PM, Travis Jensen <tr...@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.
>>>>>
>>>>
>>>
>>
Re: Confused handling of HEAD requests
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Jul 20, 2011 at 6:32 PM, Randall Leeds <ra...@gmail.com> wrote:
> On Wed, Jul 20, 2011 at 15:20, Paul Davis <pa...@gmail.com> wrote:
>> On Wed, Jul 20, 2011 at 5:15 PM, Randall Leeds <ra...@gmail.com> wrote:
>>> On Wed, Jul 20, 2011 at 15:09, Paul Davis <pa...@gmail.com> wrote:
>>>> On Wed, Jul 20, 2011 at 5:03 PM, Travis Jensen <tr...@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.
>>>>
>>>
>>
>
Re: Confused handling of HEAD requests
Posted by Randall Leeds <ra...@gmail.com>.
On Wed, Jul 20, 2011 at 15:20, Paul Davis <pa...@gmail.com> wrote:
> On Wed, Jul 20, 2011 at 5:15 PM, Randall Leeds <ra...@gmail.com> wrote:
>> On Wed, Jul 20, 2011 at 15:09, Paul Davis <pa...@gmail.com> wrote:
>>> On Wed, Jul 20, 2011 at 5:03 PM, Travis Jensen <tr...@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.
>>>
>>
>
Re: Confused handling of HEAD requests
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Jul 20, 2011 at 5:15 PM, Randall Leeds <ra...@gmail.com> wrote:
> On Wed, Jul 20, 2011 at 15:09, Paul Davis <pa...@gmail.com> wrote:
>> On Wed, Jul 20, 2011 at 5:03 PM, Travis Jensen <tr...@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.
>>
>
Re: Confused handling of HEAD requests
Posted by Randall Leeds <ra...@gmail.com>.
On Wed, Jul 20, 2011 at 15:09, Paul Davis <pa...@gmail.com> wrote:
> On Wed, Jul 20, 2011 at 5:03 PM, Travis Jensen <tr...@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.
>
> 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.
>
Re: Confused handling of HEAD requests
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Jul 20, 2011 at 5:03 PM, Travis Jensen <tr...@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?
>
> 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'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.