On Aug 19, 2008, at 11:44 PM, William A. Rowe, Jr. wrote:

William A. Rowe, Jr. wrote:
Different issue; different response.
Bill Barker wrote:
"Nick Kew" <[EMAIL PROTECTED]> wrote in message
-1. Semicolon is a perfectly valid character in a session-id, so that
risks breaking other apps.  The fact that Tomcat treats it as a
separator doesn't commit other appservers to do the same.

No, an un-escaped semicolon is a reserved character by RFC 2396, section 2.2. Since RFC 2616 section 3.2.1 uses 2396 as a reference, then an un-escaped semicolon isn't valid in a session-id.

Sorry, I answered too quickly, everything in the reserved set have
two meanings in the context of the URI

     reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                   "$" | ","

So let's study ";"'s meaning

3.3. Path Component

  The path component contains data, specific to the authority (or the
  scheme if there is no authority component), identifying the resource
  within the scope of that scheme and authority.

     path          = [ abs_path | opaque_part ]

     path_segments = segment *( "/" segment )
     segment       = *pchar *( ";" param )
     param         = *pchar

     pchar         = unreserved | escaped |
                     ":" | "@" | "&" | "=" | "+" | "$" | ","

  The path may consist of a sequence of path segments separated by a
  single slash "/" character.  Within a path segment, the characters
"/", ";", "=", and "?" are reserved. Each path segment may include a
  sequence of parameters, indicated by the semicolon ";" character.
  The parameters are not significant to the parsing of relative
  references.

This is not what Jim's patch represented, so I concur with Nick, -1 to
the patch committed.


Please note that get_path_param() is ONLY used to get the sticky
route via the session data and only in find_session_route().

In any case, I agree that both solutions are non-optimal... This
leads me to believe that whether we should treat ';' as special
for session/route data should be runtime configurable. I propose
a simple envar... Sound OK?

Reply via email to