tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <mgai...@hotmail.com>
Subject RE: troubleshooting getPathInfo in jsp files
Date Wed, 15 Dec 2010 15:23:54 GMT

Hi Gary

this copied text comes straight from the Doc:

"Java Platform Standard Ed. 7 DRAFT ea-b121

java.net.Class URI

java.lang.Object  extended by java.net.URI

All Implemented Interfaces:
    Serializable, Comparable<URI>

public final class URI extends Object implements Comparable<URI>, Serializable

Represents a Uniform Resource Identifier (URI) reference.

Aside from some minor deviations noted below, an instance of this class represents a URI reference
as defined by 
RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax, amended by 
RFC 2732: Format for Literal IPv6 Addresses in URLs. The Literal IPv6 address format also
supports scope_ids. The syntax and usage of scope_ids is described here. This class provides
constructors for creating URI instances from their components or by parsing their string forms,
methods for accessing the various components of an instance, and methods for normalizing,
resolving, and relativizing URI instances. Instances of this class are immutable.
URI syntax and components
At the highest level a URI reference (hereinafter simply "URI") in string form has the syntax

    [scheme:]scheme-specific-part[#fragment] 

where square brackets [...] delineate optional components and the characters : and # stand
for themselves.

An absolute URI specifies a scheme; 
a URI that is NOT absolute is said to be relative. 
URIs are also classified according to whether they are OPAQUE or HIERARCHICAL

An OPAQUE URI is an absolute URI whose scheme-specific part does NOT begin with a slash character
('/'). 
Opaque URIs are not subject to further parsing. Some examples of opaque URIs are:

    mailto:java-net@java.sun.com    
    news:comp.lang.java    
    urn:isbn:096139210x

A HIERARCHICAL URI is either an 
  ABSOLUTE URI (whose scheme-specific part begins with a slash character), 
  or a RELATIVE URI, that is, a URI that does not specify a scheme. 

Some examples of hierarchical URIs are:

    http://java.sun.com/j2se/1.3/
    docs/guide/collections/designfaq.html#28
    ../../../demo/jfc/SwingSet2/src/SwingSet2.java
    file:///~/calendar 

A hierarchical URI is subject to further parsing according to the syntax

    [scheme:][//authority][path][?query][#fragment] 

here the characters :, /, ?, and # stand for themselves. The scheme-specific part of a hierarchical
URI consists of the characters between the scheme and fragment components."

<snip>

"See Also:
    RFC 2279: UTF-8, a transformation format of ISO 10646,
    RFC 2373: IPv6 Addressing Architecture,
    RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax,
    RFC 2732: Format for Literal IPv6 Addresses in URLs,
    URISyntaxException, Serialized Form"

<snip>
"Copyright © 1993, 2010, Oracle Corporation. All rights reserved.
DRAFT ea-b121 "

my question is:
are you seeing implementations (in TC) of a Hierarchical URI which is NOT 
Absolute URI
or Relative URI


?
Martin Gainty 
______________________________________________ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten
wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist
unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet
keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire
prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe
quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information
seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les
email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune
responsabilité pour le contenu fourni.




> Date: Wed, 15 Dec 2010 09:48:18 -0500
> Subject: Re: troubleshooting getPathInfo in jsp files
> From: garym@teledyn.com
> To: users@tomcat.apache.org
> 
> thanks.  I just might :)  I can probably find it on Google, but would you
> happen to have the url for the jsr-315 spec?  I still find it incredible
> that a 15 year mature unix-originating project in 2010 would still be
> demanding CPM/MSDOS filename extensions and not simply using the standard
> regex library, or that java servers should be constrained not allow a
> hierarchical address space to a universal resource simply because the active
> agent in the URI happened to be a script - the supplier of a resource in a
> REST environment should be invisible to the resource requester imho, however
> it is built under the surface of the request, I think it should just be
> /a/path/on/the/web and not a?subject=path&relation=on&article=the&object=web
> :)
> 
> but yeah, I should take that up with them.
> 
> On Wed, Dec 15, 2010 at 9:33 AM, Mark Thomas <markt@apache.org> wrote:
> 
> > On 15/12/2010 14:03, Gary Lawrence Murphy wrote:
> > > On Wed, Dec 15, 2010 at 4:54 AM, Mark Thomas <markt@apache.org> wrote:
> > >
> > >> Go read the spec. The JSP Servlet is mapped *based on file extension*
> > not
> > >> path.
> > >
> > >
> > > heh, how very quaint.  Where did they get this idea?  from MSDOS? Oh
> > never
> > > mind.  I don't think I want to know, and I suppose I just should be happy
> > > the names aren't constrained to 8 ascii chars.
> >
> > If you want to lobby the Servlet Expert group to modify the mapping
> > rules to support more flexible mapping then the place to send your
> > comments is jsr-315-comments@jcp.org
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> 
> 
> -- 
> *Have Blog, Will Travel: blog.teledyn.com*
> *A Serviceable Substitute: post.teledyn.com*
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message