Hi Guys,
I too would like to access /foo and /foo/. Any updates on this?
Second, I have /foo.html that surrounds default at content. I have a
situation where / should look exactly like /foo. I don't want to
redirect to foo. How else can I achieve this without copying the
contents of
On Mon, Mar 23, 2009 at 5:03 PM, bradford fingerm...@gmail.com wrote:
Hi Guys,
I too would like to access /foo and /foo/. Any updates on this?
/foo maps to /foo.html
/foo/ maps to /foo/index.html
This has not and will not change.
If you are using SiteMap, make sure there are SiteMap
On Fri, Mar 13, 2009 at 10:21 PM, Charles F. Munat c...@munat.com wrote:
Sorry, I've missed most of this discussion, but thank you for your
responses. Hopefully, I'll be able to figure out what they mean after I
get some coffee (I had a very late night working).
I organize all my sites the
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 c...@munat.com wrote:
It
Derek,
/page is parsed to List(page) and /page/ is parsed to List(page,
index).
Unfortunately, the rewrites are applied before the sitemap is in scope, so
we can't consult the sitemap during rewrite, but I think there may be a way
to write a DispatchPF to intercept List(xxx) and redirect to
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
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
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
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
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 dchenbec...@gmail.com wrote:
Well, treating a directory without a trailing slash (/path) as the directory +
index (/path/index) is pretty
Sorry, I've missed most of this discussion, but thank you for your
responses. Hopefully, I'll be able to figure out what they mean after I
get some coffee (I had a very late night working).
I organize all my sites the same way. Names of items are expressed as
directories. All pages are called
It seems that Lift used to serve /folks/ when /folks was called, but
recently it stopped. It would be nice if it looked for a *file* with
that name first, but then tried directories if no file was found. Is
there a downside to that?
Im afraid your mistaken about it previously having
12 matches
Mail list logo
