[PATCH] unescape_url() was called for proxy requests

[Martin Kraemer <Ma...@mch.sni.de>]

In process_request_internal(), a check is made whether the URI contains
embedded %2F's, and if it does the request is immediately aborted with a
404 reply.

This breaks for, e.g., proxy requests which can legally contain %2F's
(and why should we care?). Example:

  GET http://www.novalis.fr/novalis-bin/rech_disqv?donnee_appel=NOVALIS&suite=&type=2&id=6009890655716&ld-titre=&ld-chanson=&ld-interprete=&ld-compositeur=magnard&ld-interprete=&ld-titre=&ld-support=&ld-genre=&go=Rechercher+%2F+Search HTTP/1.0

The question is whether the %2F's is important at all given the fact that
it is only part of the query arg, not part of the path. Perhaps the
unescape_url() call should be applied to r->parsed_uri.path instead (and
only if the request is not a proxy request) ?

What do you think?

    Martin
-- 
| S I E M E N S |  <Ma...@mch.sni.de>  |      Siemens Nixdorf
| ------------- |   Voice: +49-89-636-46021     |  Informationssysteme AG
| N I X D O R F |   FAX:   +49-89-636-44994     |   81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request

Re: [PATCH] unescape_url() was called for proxy requests

[Dean Gaudet <dg...@arctic.org>]

Grr, ^X instead of ^C, didn't mean to send that. 

There's probably another proxy bug right now too which occured as a result
of me fixing yet another proxy bug.  You see, we're missing at least one
API phase, or we've got one phase that's bogus.  The translate_name phase
aborts as soon as one module returns OK.  As far as I can tell, this is
absolutely wrong.  It should run through all the modules.  Because of this
I had to move proxy detection to the post_read_request phase (which does
go through all the handlers), because if the proxy was after mod_alias or
mod_rewrite it was possible the proxy wouldn't get its hand on the request
at all during this phase... and it needed to.  (Consider a request to
http://foo/cgi-bin/blah where ScriptAlias /cgi-bin/ exists and foo is a
virtualhost.) 

But the problem with moving this stuff to post_read_request is that it's
not run for sub_req_lookup_uri(). 

Personally I think unescape_url() is something that core_translate() 
should do, but it can't... because translate_name will abort before
core_translate runs if mod_alias or mod_rewrite is around.

There's more like this -- we keep special casing r->proxyreq, I don't even
think that r->proxyreq should be an element in the request_req.  What
we're doing is adding special cases to the core for one module which
aren't required, or should be handled via API phases. 

Like TRACE and OPTIONS.  Those should go through invoke_handler(), but
they don't because modules are too lame to check the access method.  We
can't implement an HTTP/1.1 proxy as it stands because TRACE is hijacked
before the proxy can do its thing.

Like the recent addition of the proxyreq and http:// scheme check before
find_types... the proxy should be able to do that itself.  find_types is
another aborting phase.  If find_types didn't abort then the proxy could
make this check itself. 

It's not trivial to change translate_names and find_types.  But more and
more I think it's necessary. 

Dean

On Mon, 23 Mar 1998, Dean Gaudet wrote:

> But the procy
> 
> On Mon, 23 Mar 1998, Martin Kraemer wrote:
> 
> > In process_request_internal(), a check is made whether the URI contains
> > embedded %2F's, and if it does the request is immediately aborted with a
> > 404 reply.
> > 
> > This breaks for, e.g., proxy requests which can legally contain %2F's
> > (and why should we care?). Example:
> > 
> >   GET http://www.novalis.fr/novalis-bin/rech_disqv?donnee_appel=NOVALIS&suite=&type=2&id=6009890655716&ld-titre=&ld-chanson=&ld-interprete=&ld-compositeur=magnard&ld-interprete=&ld-titre=&ld-support=&ld-genre=&go=Rechercher+%2F+Search HTTP/1.0
> > 
> > The question is whether the %2F's is important at all given the fact that
> > it is only part of the query arg, not part of the path. Perhaps the
> > unescape_url() call should be applied to r->parsed_uri.path instead (and
> > only if the request is not a proxy request) ?
> > 
> > What do you think?
> > 
> >     Martin
> > -- 
> > | S I E M E N S |  <Ma...@mch.sni.de>  |      Siemens Nixdorf
> > | ------------- |   Voice: +49-89-636-46021     |  Informationssysteme AG
> > | N I X D O R F |   FAX:   +49-89-636-44994     |   81730 Munich, Germany
> > ~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
> > 
> 

Re: [PATCH] unescape_url() was called for proxy requests

[Dean Gaudet <dg...@arctic.org>]

But the procy

On Mon, 23 Mar 1998, Martin Kraemer wrote:

> In process_request_internal(), a check is made whether the URI contains
> embedded %2F's, and if it does the request is immediately aborted with a
> 404 reply.
> 
> This breaks for, e.g., proxy requests which can legally contain %2F's
> (and why should we care?). Example:
> 
>   GET http://www.novalis.fr/novalis-bin/rech_disqv?donnee_appel=NOVALIS&suite=&type=2&id=6009890655716&ld-titre=&ld-chanson=&ld-interprete=&ld-compositeur=magnard&ld-interprete=&ld-titre=&ld-support=&ld-genre=&go=Rechercher+%2F+Search HTTP/1.0
> 
> The question is whether the %2F's is important at all given the fact that
> it is only part of the query arg, not part of the path. Perhaps the
> unescape_url() call should be applied to r->parsed_uri.path instead (and
> only if the request is not a proxy request) ?
> 
> What do you think?
> 
>     Martin
> -- 
> | S I E M E N S |  <Ma...@mch.sni.de>  |      Siemens Nixdorf
> | ------------- |   Voice: +49-89-636-46021     |  Informationssysteme AG
> | N I X D O R F |   FAX:   +49-89-636-44994     |   81730 Munich, Germany
> ~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
>