On Wed, 28 Feb 2001, William A. Rowe, Jr. wrote:
> From: <[EMAIL PROTECTED]>
> Sent: Wednesday, February 28, 2001 10:13 AM
>
>
> > > > > Line 845, mod_dav.c [2.0 tree]
> > > > >
> > > > > if (r->header_only) {
> > > > > ap_send_http_header(r);
> > > > > return DONE;
> > > > > }
> > > >
> > > > Handlers should not try to handle HEAD requests anymore. This should go
> > > > away completely for 2.0. Let the filters take care of the HEAD request.
> > >
> > > Wrong. Filters don't know wtf the content-type is, what the etag is, what
> > > the handler's idea of the content-location is. So they will forever handle
> > > head requests.
> >
> > Wrong. :-) Filters don't know, but the HTTP filter had better know where
> > to get that information from the request. Take a look at what you have
> > done here. Basically, you sent no data, because ap_send_http_header is a
> > no-op, then you return DONE. The core then calls
> > ap_finalize_request_protocol, which sends an brigade with just an EOS in
> > it down the stack. The http_header filter looks at the headers in the
> > request, and it all just works.
>
> We are speaking of two different things...
>
> > > I'm just confirming that returning OK (or DONE in DAV's case) pushes the
> > > headers after the handler returns.
> >
> > Yes it does, which is why handlers can completely ignore HEAD requests
> > now.
>
> No they can't. They need to look, see HEAD and return, _after_ they have
> set all the headers they care to tell the client about.
You have just tied every single handler to HTTP. They don't need to
return at all. Take a look at the http_header_filter. It will drop any
data and never send it. It then sends a return code that says, "Okay,
your done now", and the handler ends. This means that we may generate a
little bit of data, but we shouldn't have to generate all of it. I can
understand a flag that says "should I really generate content or not?",
but the handler still shouldn't return, it should send an EOS down the
filter stack.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
