filters, welcome pages

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

filters, welcome pages

Andrew Houghton
I asked about something vaguely related to this a while back --  
sometime last year, I think -- and I meant to follow up, but let it  
slide.  I've just spent a little time looking at some filter traces,  
and I see the following:

> /ftest (directory, should end up on welcome page)
>
>      [java] REQUEST entered http://localhost/ftest
>      [java] REQUEST exited http://localhost/ftest
>      [java] REQUEST entered http://localhost/ftest/
>      [java] FORWARD entered http://localhost/ftest/index.jsp
>      [java] FORWARD exited http://localhost/ftest/index.jsp
>      [java] REQUEST exited http://localhost/ftest/
>
> /ftest/ (directory, should end up on welcome page)
>
>      [java] REQUEST entered http://localhost/ftest/
>      [java] FORWARD entered http://localhost/ftest/index.jsp
>      [java] FORWARD exited http://localhost/ftest/index.jsp
>      [java] REQUEST exited http://localhost/ftest/
>
> /ftest/index.jsp (simple welcome page)
>
>      [java] REQUEST entered http://localhost/ftest/index.jsp
>      [java] REQUEST exited http://localhost/ftest/index.jsp

I tested this with 5.1.4 and 5.1.5rc2 -- they gave identical  
traces.   I'm confused by the results of the request for '/ftest' --  
is there a reason for the initial enter/exit step, rather than the  
trace I see for '/ftest/'?  Is there any way to get rid of that  
initial in-out bounce?

Thanks,

- Andrew


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: filters, welcome pages

Russell Howe
On Sat, Nov 05, 2005 at 09:37:54PM -0800, Andrew Houghton wrote:
> I asked about something vaguely related to this a while back --  
> sometime last year, I think -- and I meant to follow up, but let it  
> slide.  I've just spent a little time looking at some filter traces,  
> and I see the following:
>
> >/ftest (directory, should end up on welcome page)
> >
> >     [java] REQUEST entered http://localhost/ftest
> >     [java] REQUEST exited http://localhost/ftest

OK, so there is no /ftest file

> >     [java] REQUEST entered http://localhost/ftest/

There is a directory, however

> >     [java] FORWARD entered http://localhost/ftest/index.jsp

And in the directory is a welcome page.
>
> I tested this with 5.1.4 and 5.1.5rc2 -- they gave identical  
> traces.   I'm confused by the results of the request for '/ftest' --  
> is there a reason for the initial enter/exit step, rather than the  
> trace I see for '/ftest/'?  Is there any way to get rid of that  
> initial in-out bounce?

I think you'd need to map /ftest explicitly...

--
Russell Howe       | Why be just another cog in the machine,
[hidden email] | when you can be the spanner in the works?


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: filters, welcome pages

Andrew Houghton

On Nov 6, 2005, at 6:18 AM, Russell Howe wrote:
>
> I think you'd need to map /ftest explicitly...
>


I realized soon after I sent my message that I didn't give nearly  
enough explanation.  So, for anyone else who happens to be reading  
along, here's the missing context.

I've got what is essentially a jsp-based app, configured via jetty's  
XML configuration (not a web.xml file, though that's not particularly  
important for this issue).  I wrote a test filter that logged when  
doFilter() was entered and  exited, created four instances (one each  
for 'request', 'forward', 'include', and 'error' dispatchers), mapped  
the instances to '/*', and started playing around.

What I quoted was my trace output, not jetty's.  Everything jetty  
does with regards to filter chains matches my expectations, except  
this particular piece I quoted and asked about in the original message.

My only issue with your suggestion, Russell, is I have 470  
directories in the hierarchy under my root.  I can't really be  
expected (well, I can, I guess) to map each one separately.  Time to  
look at the source..

- a.




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: filters, welcome pages

Greg Wilkins-5

Andrew,

the reason /foo/dir is always redirected to /foo/dir/  is so the
browswer can resolve relative links correctly.

If in /foo/dir/index.html  you had <img src="logo.png"/>
then if that index file was served from  /foo/dir the browser
would look for an image at /foo/logo.png.

But if you redirect to /foo/dir/  then the browser will
correctly look for /foo/dir/logo.png

So IFF you have no relative links - you could write a filter that
forwarded requests to /foo/dir to /foo/dir/index.html   But I still
think that sux.


It would be much better for fix the links, so anywhere you have

   <a href="/foo/dir">link</a>

is replaced with

   <a href="/foo/dir/">link</a>

cheers






Andrew Houghton wrote:

>
> On Nov 6, 2005, at 6:18 AM, Russell Howe wrote:
>
>>
>> I think you'd need to map /ftest explicitly...
>>
>
>
> I realized soon after I sent my message that I didn't give nearly
> enough explanation.  So, for anyone else who happens to be reading
> along, here's the missing context.
>
> I've got what is essentially a jsp-based app, configured via jetty's
> XML configuration (not a web.xml file, though that's not particularly
> important for this issue).  I wrote a test filter that logged when
> doFilter() was entered and  exited, created four instances (one each
> for 'request', 'forward', 'include', and 'error' dispatchers), mapped
> the instances to '/*', and started playing around.
>
> What I quoted was my trace output, not jetty's.  Everything jetty  does
> with regards to filter chains matches my expectations, except  this
> particular piece I quoted and asked about in the original message.
>
> My only issue with your suggestion, Russell, is I have 470  directories
> in the hierarchy under my root.  I can't really be  expected (well, I
> can, I guess) to map each one separately.  Time to  look at the source..
>
> - a.
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: filters, welcome pages

Andrew Houghton
That makes good sense, thank you  -- I never watched the interaction  
with the browser, so it didn't even occur to me that I was seeing a  
redirect.  Somehow I though this was happening purely within the  
container.

If I just want to minimize the flow through the filter chain for a  
request that will end up being redirected, it sounds like I either  
need a handler, or the first request filter, to do a filesystem check  
and ensure that the requested URL isn't a directory.  If it is, I  
should do the redirect myself?

- a.

p.s. The more I think about this, the less important it is -- I do a  
fair amount of setup for response buffering and object pooling, but  
it should be just noise compared to the actual page handling.


On Nov 7, 2005, at 1:16 AM, Greg Wilkins wrote:

>
> Andrew,
>
> the reason /foo/dir is always redirected to /foo/dir/  is so the
> browswer can resolve relative links correctly.
>
> If in /foo/dir/index.html  you had <img src="logo.png"/>
> then if that index file was served from  /foo/dir the browser
> would look for an image at /foo/logo.png.
>
> But if you redirect to /foo/dir/  then the browser will
> correctly look for /foo/dir/logo.png
>
> So IFF you have no relative links - you could write a filter that
> forwarded requests to /foo/dir to /foo/dir/index.html   But I still
> think that sux.
>
>
> It would be much better for fix the links, so anywhere you have
>
>    <a href="/foo/dir">link</a>
>
> is replaced with
>
>    <a href="/foo/dir/">link</a>
>
> cheers
>
>
>
>
>
>
> Andrew Houghton wrote:
>>
>> On Nov 6, 2005, at 6:18 AM, Russell Howe wrote:
>>
>>>
>>> I think you'd need to map /ftest explicitly...
>>>
>>
>>
>> I realized soon after I sent my message that I didn't give nearly
>> enough explanation.  So, for anyone else who happens to be reading
>> along, here's the missing context.
>>
>> I've got what is essentially a jsp-based app, configured via jetty's
>> XML configuration (not a web.xml file, though that's not particularly
>> important for this issue).  I wrote a test filter that logged when
>> doFilter() was entered and  exited, created four instances (one each
>> for 'request', 'forward', 'include', and 'error' dispatchers), mapped
>> the instances to '/*', and started playing around.
>>
>> What I quoted was my trace output, not jetty's.  Everything jetty  
>> does
>> with regards to filter chains matches my expectations, except  this
>> particular piece I quoted and asked about in the original message.
>>
>> My only issue with your suggestion, Russell, is I have 470  
>> directories
>> in the hierarchy under my root.  I can't really be  expected (well, I
>> can, I guess) to map each one separately.  Time to  look at the  
>> source..
>>
>> - a.
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by:
>> Tame your development challenges with Apache's Geronimo App Server.
>> Download
>> it for free - -and be entered to win a 42" plasma tv or your very own
>> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.  
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> jetty-discuss mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss