Hmmm, I see your point. Will have a noodle at the weekend and see what would be the best route.
Cheers, Tim On 13/03/2009 17:45, "Derek Chen-Becker" <[email protected]> wrote: > Well, treating a directory without a trailing slash (/path) as the directory + > index (/path/index) is pretty standard behavior in web servers (Apache returns > a 301 from the former to the latter), so I think something that requires less > user intervention would be good. Perhaps at most we would want a boolean var > on LiftRules to control the behavior. > > Derek > > On Fri, Mar 13, 2009 at 12:15 PM, Timothy Perrett <[email protected]> > wrote: >> >> Im pretty sure you could just do this with the existing infrastructure >> (RewritePF and DispatchPF) >> >> For instance, if Chas doesnt mind having two seperate resources, then >> he can easily use RewritePF to get the same content at two resource >> locations. Alternatively, he could just use a 301 redirect response in >> a dispatch call to get the appropriate resource - I've posted code to >> one of his questions about that before If memory serves. >> >> I think that should all be cool? Cant think of a good reason why this >> wouldnt work anyway :-) >> >> Cheers, Tim >> >> On Mar 13, 4:57 pm, Derek Chen-Becker <[email protected]> wrote: >>> > I think I was confusing this with some other behavior of SiteMap, hence my >>> > question. I think it would be good to allow some really pre-processing of >>> > the URL. Would it useful to allow the user to control it, or do you think >>> it >>> > would be better to just make it implicit? Something like >>> > >>> > LiftRules.pathRewrite.append { >>> > case List("parse") => List("parse", "index") >>> > ... >>> > >>> > } >>> > >>> > I'm doing a lot of wand-waving there, but does that seem like a reasonable >>> > approach from the user side of things? Or maybe make a subclass of >>> > RewriteResponse that just tells Lift to modify the path but change nothing >>> > else? >>> > >>> > case class ModifiedPath (path : List[String]) extends RewriteResponse(...) >>> > >>> > Derek >>> > >>> > On Fri, Mar 13, 2009 at 10:51 AM, Timothy Perrett >>> > <[email protected]>wrote: >>> > >>>> > > Within Lift, /page does what it says on the tin, whilst /page/ actually >>>> > > works out as: >>> > >>>> > > /page/index >>> > >>>> > > IMO, this is good. If you want them to be the same, I think you could >>>> > > either do a rewrite to the same content (if memory serves there is also a >>>> > > boolean option for defining if your using the slash or not?) >>> > >>>> > > I'm pretty sure it matters not of you are or are not using site map at >>>> this >>>> > > process is part of lifts request handling. >>> > >>>> > > Does that help? >>> > >>>> > > Cheers, Tim >>> > >>>> > > Sent from my iPhone >>> > >>>> > > On 13 Mar 2009, at 14:27, Derek Chen-Becker <[email protected]> >>>> wrote: >>> > >>>> > > Hmmm. I thought that this was what normally happened with most web >>>> servers >>>> > > (Jetty included). Are you using SiteMap, by any chance? What is the >>>> > > difference that you see between a response for /page and /page/ ? >>> > >>>> > > Derek >>> > >>>> > > On Fri, Mar 13, 2009 at 4:33 AM, Charles F. Munat < <[email protected]> >>>> > > [email protected]> wrote: >>> > >>>>> > >> It would be advantageous for me, given the way I organize my sites, if >>>>> > >> requests for /page were served the same way as requests for /page/, or >>>>> > >> at least /page redirected to /page/. >>> > >>>>> > >> Is there an easy way to do this? >>> > >>>>> > >> Thanks, >>>>> > >> Chas. >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
