httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: ugly problem with sub-requests
Date Tue, 23 Feb 1999 22:37:51 GMT
Dean Gaudet wrote:
> On Tue, 23 Feb 1999, Greg Stein wrote:
> ...
> > This is reasonably straight-forward. The sub-req mechanism doesn't take
> > an absolute URI, so I do some munging before calling it. Not a big deal,
> > although it would be nice to see the sub-req system take absolute URIs.
> 
> Huh?  ap_sub_req_lookup_uri() :
> ...
> That looks like it supports absolute uris to me... or are you talking
> about http://foo/blah ?

Absolute URIs are defined in the RFCs to include the hostname.
Otherwise, the URI is relative to the host. :-)

> Supporting hostnames there is a total pain in the ass -- because vhosts
> just aren't as clean as everyone pretends they are.

No doubt. I use ap_matches_request_vhost(). I don't remember the
specifics, but when I implemented that, I recall that the vhost
situation was quite shaky. For example, "localhost" or "kurgan" would
not match "kurgan.lyra.org". So my destination URIs always had to be
fully-qualified (sigh).

> > The *real* problem here is with ap_set_sub_req_protocol(). It hard-codes
> > the sub-request to use the "GET" method. For mod_dav, this means that
> > the target is authorized as a GET rather than a MOVE.
> 
> I wonder what breaks if you just copy the protocol.  Protocols expecting
> request bodies can't be copied... but perhaps they shouldn't be able to
> succeed in performing a subrequest -- or rather, later on when a module
> attempts to access the body it should get an error.

I tried the hack that I mentioned in my email: reset the method and
rerun the auth/auth stages. It seems to work as I'd like. However, I
just *know* there will be a module out there that is going to puke
because it was run twice for the same request.

Here are the standard modules that use sub-requests and what HTTP
methods they might be using when the sub_req is issued:

  mod_autoindex     GET only
  mod_cern_meta     any
  mod_dir           any
  mod_include       GET only
  mod_mime_magic    any
  mod_negotiation   any?
  mod_rewrite       any
  mod_isapi         any

However, the question is really what happens to somebody that processes
alternative methods when they are part of a sub-request? I can say that
mod_dav wouldn't be bothered: the bulk of it is a handler. There is a
type_checker, which sets the handler based on the method; with or
without the proper method, mod_dav is uninvolved in a sub_req (unless it
is run, of course).

If necessary, a module can always tell it is a subrequest and avoid
processing of a body. However, if it gets there, then it probably is an
error.

I'm not sure that I'd recommend simply changing
ap_set_sub_req_protocol() to simply copying over the method. The
semantics of the sub-request might actually be "do a GET request". I
would probably request a function just like ap_sub_req_lookup_uri(), but
where I can pass a method. It would set the method and method_number
from the argument, but otherwise behave the same.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Mime
View raw message