You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jon Stevens <jo...@latchkey.com> on 2001/09/30 22:25:06 UTC
Before I file a bug report...
I want to get confirmation that this is a valid url:
http://localhost:8080/examples/jsp/snp/snoop.jsp/foo
Where:
PATH_INFO=/foo
The error that I get right now is:
HTTP Status 404 - /jsp/snp/snoop.jsp/foo
The requested resource (/jsp/snp/snoop.jsp/foo) is not available.
Please note that:
http://localhost:8080/context/servlet/Bar/foo
Works just fine. I don't see why it shouldn't also work with file extension
mapping.
thanks,
-jon
Re: Before I file a bug report...
Posted by Remy Maucherat <rm...@home.com>.
> on 9/30/01 3:15 PM, "Remy Maucherat" <rm...@home.com> wrote:
>
> > Mmmm, I'm not too sure about all this.
> > The servlet spec seems to imply that the extension mapping is on the end
of
> > the path.
> >
> > Section 11.1, item #3 : If the last segment in the URL path contains an
> > extension (e.g. .jsp), the servlet container will try to match a servlet
> > that handles requests for the extension.
> > An extension is defined as the part of the last segment after the last
'.'
> > character.
> >
> > Remy
>
> I think the Servlet Spec is wrong then because HTTP says that anything
after
> the extension mapping is PATH_INFO. It Is also inconsistent with the way
> that servlet path mapping works as well.
We're supposed to implement path mapping the way it is specified in the
servlet API. So if I read the spec correctly, it says that /foo.jsp goes to
the *.jsp mapping, and /foo.jsp/bar goes to the default servlet, since here
/bar would be the last segment of the URI.
Remy
Re: SCRIPT_NAME and PATH_INFO with extension mapping
Posted by Jon Stevens <jo...@latchkey.com>.
We are now discussing this problem on JSR-053's mailing list. It turns out
that several other vendors break the spec and do somewhat close to the right
thing. :-)
Unfortunately, due to the politics at Sun, only members of the JSR can see
this discussion. Sorry.
-jon
RE: SCRIPT_NAME and PATH_INFO with extension mapping
Posted by Marc Saegesser <ma...@apropos.com>.
I agree that prohibitting PATH_INFO for extension mapped servlets is not
good. But, a lot of people have been throwing things like "this violates
the HTTP specification" or "this violates the HTML specification". Would
someone please show me where either of these specifications makes any
mention of PATH_INFO?
PATH_INFO is a CGI concept and CGI is a finalist for the least specified
specification award.
Also, the CGI specification does not describe any methods for mapping URLs
to CGI applications, this is a function of the Web server, so it doesn't
really help much in the debate over how PATH_INFO should be treated with
extension mappings vs. prefix mappings. That said, what little information
is provided in the specification would lend credence to the side (my side,
actually) that PATH_INFO should be available in either case. Here's the
section on the PATH_INFO environment variable:
-------
- PATH_INFO
The extra path information, as given by the client. In other words, scripts
can be accessed by their virtual pathname, followed by extra information at
the end of this path. The extra information is sent as PATH_INFO. This
information should be decoded by the server if it comes from a URL before it
is passed to the CGI script.
-------
Since this stuff has *nothing* to do with HTTP or HTML, the servlet
specification is free to specify what getPathInfo() returns however it
pleases. The examples provided on this thread provide good reasons why the
existing specification is lacking and I think it should be changed. Lets
just understand why it needs changed and not through non-existent
specification violation claims.
Marc Saegesser
> -----Original Message-----
> From: Christopher Cain [mailto:ccain@mhsoftware.com]
> Sent: Monday, October 01, 2001 1:04 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: SCRIPT_NAME and PATH_INFO with extension mapping
>
>
> Quoting Jon Stevens <jo...@latchkey.com>:
>
> > I'm a member of JSR-053. I will work to change it for the next release
> > of the spec.
>
> Cool. From what I've heard, the entire TC developer community is
> behind you
> 100%. Hell, even Costin agrees with you ... now *that's* truly a
> red letter day
> =)
>
> > Needless to say, this has a serious impact on Turbine's ability to
> > function.
> > It is complete bullshit that it works fine if defined through a servlet,
> > but not with extension mapping.
> >
> > This works:
> > http://www.foo.com/context/servlet/Turbine/template/Foo.vm
> >
> > This doesn't:
> > http://www.foo.com/context/Foo.vm/bar/ack
> >
> > As a result, there is no way for Turbine to work properly with
> > extension mapping because it relies on passing information in the
> > PATH_INFO and not QUERY_STRING because of the need for search
> > engines to be able to archive website information.
>
> That sucks, bro. I empathize. I don't know that much about Turbine, to be
> honest, but would my proposed change to respecting the HTML spec
> for static
> content help out with the second case above? I know it's not
> really static, but
> if it's outside of the explicit servlet area, would it fall under
> the auspices
> of the servlet behavior or the static behavior? Or am I just
> reaching for a
> loophole? :)
>
> - Christopher
>
> /**
> * Pleurez, pleurez, mes yeux, et fondez vous en eau!
> * La moitié de ma vie a mis l'autre au tombeau.
> * ---Corneille
> */
Re: SCRIPT_NAME and PATH_INFO with extension mapping
Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting Jon Stevens <jo...@latchkey.com>:
> I'm a member of JSR-053. I will work to change it for the next release
> of the spec.
Cool. From what I've heard, the entire TC developer community is behind you
100%. Hell, even Costin agrees with you ... now *that's* truly a red letter day
=)
> Needless to say, this has a serious impact on Turbine's ability to
> function.
> It is complete bullshit that it works fine if defined through a servlet,
> but not with extension mapping.
>
> This works:
> http://www.foo.com/context/servlet/Turbine/template/Foo.vm
>
> This doesn't:
> http://www.foo.com/context/Foo.vm/bar/ack
>
> As a result, there is no way for Turbine to work properly with
> extension mapping because it relies on passing information in the
> PATH_INFO and not QUERY_STRING because of the need for search
> engines to be able to archive website information.
That sucks, bro. I empathize. I don't know that much about Turbine, to be
honest, but would my proposed change to respecting the HTML spec for static
content help out with the second case above? I know it's not really static, but
if it's outside of the explicit servlet area, would it fall under the auspices
of the servlet behavior or the static behavior? Or am I just reaching for a
loophole? :)
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
* ---Corneille
*/
Re: SCRIPT_NAME and PATH_INFO with extension mapping
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/30/01 10:30 PM, "Christopher Cain" <cc...@mhsoftware.com> wrote:
> It's unfortunate that this didn't come up a few weeks ago, before the
> finalization. I'll add my voice to the general sentiment that the servlet spec
> really should've have tried to supercede the HTML spec on this, whether they
> thought the HTML spec was wrong or not. Conflicting specs are generally a
> bigger PITA than whatever was wrong with the first spec.
>
> In any case, I would have to agree that we cannot blatantly ignore something
> that is explicitly disallowed in the servlet spec. One reasonable solution
> that
> comes to mind would be to follow the servlet/jsp spec for servlets and jsp,
> and
> to follow the HTML spec for static content. But then again, it's a little
> strange to have differing behaviors based on the type of content being served.
> Throw mapping in there, and it muddies the waters even more. I just think that
> there is a point to be made, however, that any static content being served up
> by TC does not conform to the HTML spec.
>
> Did I mention that this is a really unfortunate problem? :)
I'm a member of JSR-053. I will work to change it for the next release of
the spec.
Needless to say, this has a serious impact on Turbine's ability to function.
It is complete bullshit that it works fine if defined through a servlet, but
not with extension mapping.
This works:
http://www.foo.com/context/servlet/Turbine/template/Foo.vm
This doesn't:
http://www.foo.com/context/Foo.vm/bar/ack
As a result, there is no way for Turbine to work properly with extension
mapping because it relies on passing information in the PATH_INFO and not
QUERY_STRING because of the need for search engines to be able to archive
website information.
-jon
Re: SCRIPT_NAME and PATH_INFO with extension mapping
Posted by Christopher Cain <cc...@mhsoftware.com>.
It's unfortunate that this didn't come up a few weeks ago, before the
finalization. I'll add my voice to the general sentiment that the servlet spec
really should've have tried to supercede the HTML spec on this, whether they
thought the HTML spec was wrong or not. Conflicting specs are generally a
bigger PITA than whatever was wrong with the first spec.
In any case, I would have to agree that we cannot blatantly ignore something
that is explicitly disallowed in the servlet spec. One reasonable solution that
comes to mind would be to follow the servlet/jsp spec for servlets and jsp, and
to follow the HTML spec for static content. But then again, it's a little
strange to have differing behaviors based on the type of content being served.
Throw mapping in there, and it muddies the waters even more. I just think that
there is a point to be made, however, that any static content being served up
by TC does not conform to the HTML spec.
Did I mention that this is a really unfortunate problem? :)
Quoting Bill Barker <wb...@wilshire.com>:
> As much as my personal preference is the same as Jon and Costin, it
> seems that section 11.1 rule #3 explicitly dis-allows extension
> mappings to have a PATH_INFO.
> <spec-quote>
> If the last segment in URL path contains an extension (e.g .jsp) the
> servlet
> container will try to match a servlet that handles requests for the
> extension. An extension is defined as the part of the last segment after
> the
> last '.' character.
> </spec-quote>
> This is from the 2.3 Spec, since Jon is a 4.0 user.
>
> ----- Original Message -----
> From: "Jon Stevens" <jo...@latchkey.com>
> To: "tomcat-dev" <to...@jakarta.apache.org>
> Sent: Sunday, September 30, 2001 3:49 PM
> Subject: SCRIPT_NAME and PATH_INFO with extension mapping
>
>
> > on 9/30/01 5:47 PM, "cmanolache@yahoo.com" <cm...@yahoo.com>
> wrote:
> >
> > > the conclusion was that the HTTP spec is wrong and we should
> > > follow the Servlet spec.
> >
> > That is complete BS. The servlet spec shouldn't 'override' what is
> defined
> > in the HTTP spec unless absolutely necessary. This is definitely not
> a
> > necessary case, but instead an act of stupidity.
> >
> > > Workaround - declare each page with exact mappings in web.xml.
> >
> > Making me specify each and every page in my webapp in the web.xml is
> just
> > plain BS.
> >
> > I bet that a URL like this works:
> >
> > http://www.foo.com/MicrosoftIsBetterThanSun.asp/foo/bar
> >
> > I *know* that this URL works:
> >
> > http://www.foo.com/PHPIsBetterThanJSP.php/foo/bar
> >
> > Essentially, what you are doing by removing this capability is
> preventing
> > the SCRIPT_NAME from having PATH_INFO and that is not right according
> to
> the
> > HTTP spec. I don't think that a Servlet container can override the
> behavior
> > of the HTTP spec and still claim HTTP compliance.
> >
> > -jon
> >
> >
>
>
> *----*
>
> This message is intended only for the use of the person(s) listed above
>
> as the intended recipient(s), and may contain information that is
> PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
> you may not read, copy, or distribute this message or any attachment.
>
> If you received this communication in error, please notify us
> immediately
> by e-mail and then delete all copies of this message and any
> attachments.
>
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent
>
> through the Internet is not secure. Do not send confidential or
> sensitive
> information, such as social security numbers, account numbers, personal
>
> identification numbers and passwords, to us via ordinary (unencrypted)
>
> e-mail.
>
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
* ---Corneille
*/
Re: SCRIPT_NAME and PATH_INFO with extension mapping
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/30/01 8:45 PM, "Bill Barker" <wb...@wilshire.com> wrote:
> As much as my personal preference is the same as Jon and Costin, it seems
> that section 11.1 rule #3 explicitly dis-allows extension mappings to have a
> PATH_INFO.
> <spec-quote>
> If the last segment in URL path contains an extension (e.g .jsp) the servlet
> container will try to match a servlet that handles requests for the
> extension. An extension is defined as the part of the last segment after the
> last '.' character.
> </spec-quote>
> This is from the 2.3 Spec, since Jon is a 4.0 user.
The spec is wrong.
-jon
Re: SCRIPT_NAME and PATH_INFO with extension mapping
Posted by Bill Barker <wb...@wilshire.com>.
As much as my personal preference is the same as Jon and Costin, it seems
that section 11.1 rule #3 explicitly dis-allows extension mappings to have a
PATH_INFO.
<spec-quote>
If the last segment in URL path contains an extension (e.g .jsp) the servlet
container will try to match a servlet that handles requests for the
extension. An extension is defined as the part of the last segment after the
last '.' character.
</spec-quote>
This is from the 2.3 Spec, since Jon is a 4.0 user.
----- Original Message -----
From: "Jon Stevens" <jo...@latchkey.com>
To: "tomcat-dev" <to...@jakarta.apache.org>
Sent: Sunday, September 30, 2001 3:49 PM
Subject: SCRIPT_NAME and PATH_INFO with extension mapping
> on 9/30/01 5:47 PM, "cmanolache@yahoo.com" <cm...@yahoo.com> wrote:
>
> > the conclusion was that the HTTP spec is wrong and we should
> > follow the Servlet spec.
>
> That is complete BS. The servlet spec shouldn't 'override' what is defined
> in the HTTP spec unless absolutely necessary. This is definitely not a
> necessary case, but instead an act of stupidity.
>
> > Workaround - declare each page with exact mappings in web.xml.
>
> Making me specify each and every page in my webapp in the web.xml is just
> plain BS.
>
> I bet that a URL like this works:
>
> http://www.foo.com/MicrosoftIsBetterThanSun.asp/foo/bar
>
> I *know* that this URL works:
>
> http://www.foo.com/PHPIsBetterThanJSP.php/foo/bar
>
> Essentially, what you are doing by removing this capability is preventing
> the SCRIPT_NAME from having PATH_INFO and that is not right according to
the
> HTTP spec. I don't think that a Servlet container can override the
behavior
> of the HTTP spec and still claim HTTP compliance.
>
> -jon
>
>
*----*
This message is intended only for the use of the person(s) listed above
as the intended recipient(s), and may contain information that is
PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any attachment.
If you received this communication in error, please notify us immediately
by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
Re: SCRIPT_NAME and PATH_INFO with extension mapping
Posted by Bill Barker <wb...@wilshire.com>.
Actually, Google is one of the few sites that do cache pages with query
strings (try searching for "tmwx" if you don't believe me).
----- Original Message -----
From: "Jon Stevens" <jo...@latchkey.com>
To: "tomcat-dev" <to...@jakarta.apache.org>
Sent: Sunday, September 30, 2001 6:37 PM
Subject: Re: SCRIPT_NAME and PATH_INFO with extension mapping
> on 9/30/01 7:16 PM, "cmanolache@yahoo.com" <cm...@yahoo.com> wrote:
>
> > Well, I agree with you - but I feel ofended by the 'you' in this
> > phrase. I didn't removed it - I spent quite a bit of time and arguments
to
> > keep it in.
> >
> > BTW, it has nothing to do with the HTTP spec ( which doesn't specify
> > anything like that), but with the way all known web servers operate.
> > And it has nothing to do with JSPs as well - it's true for any extension
> > mapped servlets.
> >
> > Costin
>
> The implications of this are HUGE though and it really needs to be fixed
> back. It essentially means that it is impossible to use suffix mapping in
> order to have a searchable website. In other words, Google.com doesn't
cache
> websites with a "?" in the URL. If we can't pass GET parameters via
> PATH_INFO, then where/how can we pass this information around?
>
> -jon
>
>
*----*
This message is intended only for the use of the person(s) listed above
as the intended recipient(s), and may contain information that is
PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any attachment.
If you received this communication in error, please notify us immediately
by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
Re: SCRIPT_NAME and PATH_INFO with extension mapping
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/30/01 7:16 PM, "cmanolache@yahoo.com" <cm...@yahoo.com> wrote:
> Well, I agree with you - but I feel ofended by the 'you' in this
> phrase. I didn't removed it - I spent quite a bit of time and arguments to
> keep it in.
>
> BTW, it has nothing to do with the HTTP spec ( which doesn't specify
> anything like that), but with the way all known web servers operate.
> And it has nothing to do with JSPs as well - it's true for any extension
> mapped servlets.
>
> Costin
The implications of this are HUGE though and it really needs to be fixed
back. It essentially means that it is impossible to use suffix mapping in
order to have a searchable website. In other words, Google.com doesn't cache
websites with a "?" in the URL. If we can't pass GET parameters via
PATH_INFO, then where/how can we pass this information around?
-jon
Re: SCRIPT_NAME and PATH_INFO with extension mapping
Posted by cm...@yahoo.com.
On Sun, 30 Sep 2001, Jon Stevens wrote:
> on 9/30/01 5:47 PM, "cmanolache@yahoo.com" <cm...@yahoo.com> wrote:
>
> > the conclusion was that the HTTP spec is wrong and we should
> > follow the Servlet spec.
>
> That is complete BS. The servlet spec shouldn't 'override' what is defined
> in the HTTP spec unless absolutely necessary. This is definitely not a
> necessary case, but instead an act of stupidity.
>
> > Workaround - declare each page with exact mappings in web.xml.
>
> Making me specify each and every page in my webapp in the web.xml is just
> plain BS.
>
> I bet that a URL like this works:
>
> http://www.foo.com/MicrosoftIsBetterThanSun.asp/foo/bar
>
> I *know* that this URL works:
>
> http://www.foo.com/PHPIsBetterThanJSP.php/foo/bar
>
> Essentially, what you are doing by removing this capability is preventing
> the SCRIPT_NAME from having PATH_INFO and that is not right according to the
> HTTP spec. I don't think that a Servlet container can override the behavior
> of the HTTP spec and still claim HTTP compliance.
Well, I agree with you - but I feel ofended by the 'you' in this
phrase. I didn't removed it - I spent quite a bit of time and arguments to
keep it in.
BTW, it has nothing to do with the HTTP spec ( which doesn't specify
anything like that), but with the way all known web servers operate.
And it has nothing to do with JSPs as well - it's true for any extension
mapped servlets.
Costin
SCRIPT_NAME and PATH_INFO with extension mapping
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/30/01 5:47 PM, "cmanolache@yahoo.com" <cm...@yahoo.com> wrote:
> the conclusion was that the HTTP spec is wrong and we should
> follow the Servlet spec.
That is complete BS. The servlet spec shouldn't 'override' what is defined
in the HTTP spec unless absolutely necessary. This is definitely not a
necessary case, but instead an act of stupidity.
> Workaround - declare each page with exact mappings in web.xml.
Making me specify each and every page in my webapp in the web.xml is just
plain BS.
I bet that a URL like this works:
http://www.foo.com/MicrosoftIsBetterThanSun.asp/foo/bar
I *know* that this URL works:
http://www.foo.com/PHPIsBetterThanJSP.php/foo/bar
Essentially, what you are doing by removing this capability is preventing
the SCRIPT_NAME from having PATH_INFO and that is not right according to the
HTTP spec. I don't think that a Servlet container can override the behavior
of the HTTP spec and still claim HTTP compliance.
-jon
Re: Before I file a bug report...
Posted by cm...@yahoo.com.
On Sun, 30 Sep 2001, Jon Stevens wrote:
> > Mmmm, I'm not too sure about all this.
> > The servlet spec seems to imply that the extension mapping is on the end of
> > the path.
> >
> > Section 11.1, item #3 : If the last segment in the URL path contains an
> > extension (e.g. .jsp), the servlet container will try to match a servlet
> > that handles requests for the extension.
> > An extension is defined as the part of the last segment after the last '.'
> > character.
> >
> > Remy
>
> I think the Servlet Spec is wrong then because HTTP says that anything after
> the extension mapping is PATH_INFO. It Is also inconsistent with the way
> that servlet path mapping works as well.
Well, I agree with Jon, but we had this whole discussion almost a year
ago, and the conclusion was that the HTTP spec is wrong and we should
follow the Servlet spec.
Older versions of tomcat supported path info on extension mapped servlets,
that was removed since it was considered a spec compliance bug.
Workaround - declare each page with exact mappings in web.xml.
Costin
Re: Before I file a bug report...
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/30/01 3:15 PM, "Remy Maucherat" <rm...@home.com> wrote:
> Mmmm, I'm not too sure about all this.
> The servlet spec seems to imply that the extension mapping is on the end of
> the path.
>
> Section 11.1, item #3 : If the last segment in the URL path contains an
> extension (e.g. .jsp), the servlet container will try to match a servlet
> that handles requests for the extension.
> An extension is defined as the part of the last segment after the last '.'
> character.
>
> Remy
I think the Servlet Spec is wrong then because HTTP says that anything after
the extension mapping is PATH_INFO. It Is also inconsistent with the way
that servlet path mapping works as well.
-jon
Re: Before I file a bug report...
Posted by Remy Maucherat <rm...@home.com>.
> Ok, I have found the problem. It is a result of an incorrectly written
piece
> of code in StandardContextMapper.map() under // Rule 3
>
> I'm working on a rewrite that will parse things the way that they should
be
> parsed. :-) The issue is that the relativeURI variable can be pretty much
> anything so it is difficult to figure out what the actual file suffix is
out
> of the path...
>
> Some initial testing shows that the relativeURI variable could be any
number
> of bits of information...
>
> uri: /Links.vm
> uri: /Links.vm/foo/bar
> uri: /Links.vm;foo/bar
> uri: /Links.vm:foo/bar
> uri: /Links.vm.foo/bar
>
> So, what I'm going to do is start at the first "." and then attempt to
> resolve each additional character in the URI after the period against the
> context.findServletMapping() until a match is found or the end of the URI
is
> reached.
Mmmm, I'm not too sure about all this.
The servlet spec seems to imply that the extension mapping is on the end of
the path.
Section 11.1, item #3 : If the last segment in the URL path contains an
extension (e.g. .jsp), the servlet container will try to match a servlet
that handles requests for the extension.
An extension is defined as the part of the last segment after the last '.'
character.
Remy
Re: Before I file a bug report...
Posted by Jon Stevens <jo...@latchkey.com>.
Ok, I have found the problem. It is a result of an incorrectly written piece
of code in StandardContextMapper.map() under // Rule 3
I'm working on a rewrite that will parse things the way that they should be
parsed. :-) The issue is that the relativeURI variable can be pretty much
anything so it is difficult to figure out what the actual file suffix is out
of the path...
Some initial testing shows that the relativeURI variable could be any number
of bits of information...
uri: /Links.vm
uri: /Links.vm/foo/bar
uri: /Links.vm;foo/bar
uri: /Links.vm:foo/bar
uri: /Links.vm.foo/bar
So, what I'm going to do is start at the first "." and then attempt to
resolve each additional character in the URI after the period against the
context.findServletMapping() until a match is found or the end of the URI is
reached.
Something like (untested):
String dotToEnd = relativeURI.substring(relativeURI.indexOf('.'))
StringBuffer sb = new StringBuffer();
for (int i=0; i<dotToEnd .length(); i++)
{
sb.append(dotToEnd.charAt(i));
wrapper = (Wrapper) context.findChild(sb.toString());
if (wrapper != null) {
break;
}
}
Then, once I know the suffix, I will make everything following the suffix
PATH_INFO.
I should be protected against DOS attacks of really long URI's by the
limited length that Catalina will accept for URI's.
-jon
on 9/30/01 1:25 PM, "Jon Stevens" <jo...@latchkey.com> wrote:
> I want to get confirmation that this is a valid url:
>
> http://localhost:8080/examples/jsp/snp/snoop.jsp/foo
>
> Where:
>
> PATH_INFO=/foo
>
> The error that I get right now is:
>
> HTTP Status 404 - /jsp/snp/snoop.jsp/foo
> The requested resource (/jsp/snp/snoop.jsp/foo) is not available.
>
> Please note that:
>
> http://localhost:8080/context/servlet/Bar/foo
>
> Works just fine. I don't see why it shouldn't also work with file extension
> mapping.
>
> thanks,
>
> -jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>