On Mon, 2007-12-10 at 10:00 -0500, Vadim Gritsenko wrote:
> On Dec 10, 2007, at 3:40 AM, Thorsten Scherler wrote:
> 
> > I ended up with:
> >
> > <!-- This will match all extension less requests -->
> >      <map:match type="regexp" pattern="^[^.]+$">
> >        <!-- This will match all requests having "/" on the end -->
> >        <map:match type="regexp" pattern="^(.*)/$">
> >          <map:match pattern="*/">
> >            <map:redirect-to uri="../{1}.html" />
> 
> This is a browser redirect, so user will ultimately see .../foo.html  
> URL in the browser. In this case, why would you start with a URL  
> without extension? I does not make any sense. Just use URL with  
> extension from the beginning.

lol, tell it my client.

The problem is when you do not do the rewrite you will end up to use
absolute urls for all images, css, etc. since the client browser will
interpret the "/" on the end as directory screwing up the relative
imports. Meaning you have either lots of test whether or not we have "/"
on the end or do a rewrite. 

> 
> 
> >          </map:match>
> >          <map:match pattern="**/*/">
> >            <map:redirect-to uri="../{2}.html" />
> >          </map:match>
> >        </map:match>
> >        <map:match pattern="**/*">
> >          <map:redirect-to uri="{2}.html" />
> >        </map:match>
> >        <map:match pattern="*">
> >          <map:redirect-to uri="{1}.html" />
> >        </map:match>
> >      </map:match>
> 
> Regardless of comment above, what you got here is too verbose, you can  
> DRY it down using smarter match pattern. For example:
> 
>    <map:match pattern="^(?:[^.\/]*\/)*([^.\/]+)\/$">
>      <map:redirect-to uri="../{1}.html"/>
>    </map:match>
>    <map:match pattern="^(?:[^.\/]*\/)*([^.\/]+)$">
>      <map:redirect-to uri="{1}.html"/>
>    </map:match>
> 

Hmm, sorry but the above is not working for me.

> 
> > One side effect is that the app is now way slower if you use
> > "extensionless requests". In our application we need the extensions to
> > trigger the correct pipelines, which I consider the normal usage of
> > cocoon. By redirecting the request one is causing more processing on  
> > the
> > app which explains the higher response time.
> 
> You probably mean "more round trips". I don't see any extra processing  
> on the app.

Yeah, I meant more round trips.

Thanks for your feedback.

salu2

> 
> Vadim
> 
> 
> > That makes me wonder whether extension less requests makes sense at  
> > all
> > in a multi-output-format environment.
> >
> > WDYT?
> >
> > salu2
> > -- 
> > Thorsten Scherler                                  
> > thorsten.at.apache.org
> > Open Source Java                      consulting, training and  
> > solutions
> 
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions

Reply via email to