[PATCH] Re: mod_speling (fwd)

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

On Thu, Jan 01, 1998 at 10:28:35AM -0700, Marc Slemko wrote:
> The below is a valid issue, but I'm not sure that returning a full path is
> the right answer.  A "../foo" may be better.

No, I think Soeren is right. The browser requested .../bar/AKS which
was not found. mod_speling then searches .../bar (which exists) and
finds aks and AKs. If mod_speling were to return "../AKs" then the
browser would see .../bar/AKS/../AKs -- yes, it would probably strip
away the "AKS/../" part, but anyway, .../bar/AKS/../AKs is not really a
valid path. The better approach (which is used by mod_speling in the case
of a single match anyway) is a redirection to the absolute path.

Soeren, can you please test if the appended patch fixes it for you?

The patch contains:
  * a fix to the absolute vs. relative HREF generation, as by your proposal
  * a fix for mod_speling doing the wrong thing for a request to "/" in
    some rare situations (esp. when mod_mime is not compiled in)
  * indentaion fixes a la apache style guide.

  Martin

> ---------- Forwarded message ----------
> >Newsgroups: comp.infosystems.www.servers.unix
> >From: ROBINTON@AMTRASH.comlink.de (Soeren Ziehe)
> 
> Hi,
> 
> In toying around with mod_speling under apache 1.3b3 I noticed a  
> problem.
> 
> If you have two directories with similar names mod_speling presents  
> you a page on which to choose the correct one. Depending on the way  
> you requested the directory (with or without trailing /) it works as  
> it should or you get stuck in a logical loop.
> 
> e.g. /.../AKs/
>      /.../aks/
> 
> if you request /.../AKS
> the resulting pages presents <A HREF="AKs"> and <A HREF="aks">
> Choosing either one will get you to the right directory.
> 
> _but_ if you request /.../AKS/
> the resulting pages _still_ presents <A HREF="AKs"> and <A HREF="aks">
> 
> Now this is interpreted as
>   /.../AKS/AKs
>   /.../AKS/aks
> which is of course wrong and will present you again with a page to  
> choose from. This again has the same problem and so on and on...
> 
> IMHO mod_speling should present the _absolute_ path to the  
> alternatives to choose from e.g. '/.../AKs/' instead of 'AKs'.
-- 
| 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] mod_speling [300] Multiple Choices bug (Take 2)

[Dirk-Willem van Gulik <Di...@jrc.it>]

+1 tested. But if I have some time I'd like to chase memory; seems
a bit over the top.

Dw.

Re: [PATCH] mod_speling [300] Multiple Choices bug (Take 2)

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

+1 untested. 

Note your XXX regarding allocating lots of memory can be alleviated by
creating a sub_pool to do the work, and then just passing the t from the
sub_pool into table_set since it will be pstrdup()d into the main pool
when done.  It's still kind of yucky, but the memory is reclaimed this
way. 

Dean

[PATCH] mod_speling [300] Multiple Choices bug (Take 2)

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

On Fri, Jan 09, 1998 at 12:05:20PM +0100, Martin Kraemer wrote:
> Soeren, can you please test if the appended patch fixes it for you?

That was not the answer, of course. The "[300] Multiple Choices" links
of mod_speling were totally broken:

* they neither contained the absolute URI
  (this would have broken requests of
  "/.../valid_dir/invalid_dir/and/more/stuff/": if "invalid_dir" would
  result in ``Multiple Choices'' then they would be
  interpreted as "/.../valid_dir/invalid_dir/and/more/stuff/choice1" by the
  browser;       "/.../valid_dir/choice1/and/more/stuff/" would have been
  correct)

* they also forgot to append the trailing stuff: the first patch would
  return a link  "/.../valid_dir/choice1" instead of the more
  correct link   "/.../valid_dir/choice1/and/more/stuff/" for the example
  given above.

Try this patch.

   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