Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4E525E79.2050209@christopherschultz.net>
Date: Mon, 22 Aug 2011 09:49:45 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: / on end of context paths breaking existing apps
References: 
 <CALkcCptQaMLrQMNtr2E2fY2t_hP-x9o2y1pbbGLqWtaiE394=Q@mail.gmail.com>
In-Reply-To: 
 <CALkcCptQaMLrQMNtr2E2fY2t_hP-x9o2y1pbbGLqWtaiE394=Q@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig0569D538C9D6A4CB53B3E0DE"

--------------enig0569D538C9D6A4CB53B3E0DE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Tim,

On 8/21/2011 5:49 PM, Tim Whittington wrote:
> The change in [1] has broken existing behaviour in some applications.

To echo some of Mark's comments:

> Consider the following situation:
> - An application is context path /application
> - The application has a servlet mapped to /*

So, the only valid URIs should be of the form "/application/*". Note the
/ before the *.

If you could map something to, say, "*" (no leading slash), then maybe
this could be considered a bug, but since the simplest possible valid
URI that maps to your webapp is actually "/application/", I don't think
it's a bug.

Now, it may be interfering with your webapp's operation, but that's a
different story. :)

> This seems wrong - we're considering a path as being part of a
> context, but establishing a session that will not include that path
> (for some browsers at least).

Who is "we", here? The URI path "/application" is the "context path",
but not a valid URI within that context. To get a valid URI, you need to
add something that starts with a /.

> This notably makes Cookie based session tracking inconsistent with URL
> rewriting.

Does it? How?

What part of your webapp chokes when cookies are received with a path
prefix of "/application/" instead of "/application"?

-chris


--------------enig0569D538C9D6A4CB53B3E0DE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5SXnsACgkQ9CaO5/Lv0PDw/ACdEgZoUao5yktjseHHJe0MXx7K
xZAAoKRY2ozA1/6s0t2icg2kHD9gqQyr
=lozB
-----END PGP SIGNATURE-----

--------------enig0569D538C9D6A4CB53B3E0DE--