couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Confused handling of HEAD requests
Date Thu, 21 Jul 2011 17:05:54 GMT
On Jul 21, 2011 2:33 AM, "Jan Lehnardt" <jan@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message