"Nick Kew" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > [EMAIL PROTECTED] wrote: > >> - path = apr_strtok(apr_pstrdup(pool, path), "?&", &q); >> + path = apr_strtok(apr_pstrdup(pool, path), ";?&", &q); > > -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. There's a > case for mod_jk-compatibility in mod_proxy_ajp, not mod_proxy_balancer. > > (Unless someone convinces me otherwise) >
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. Of course the patch doesn't totally work since something like: http://www.myfirm.com/myapp;foo=bar/mycontext;user=me/mypage.jsp;jsessionid=xxyyzz is perfectly valid, and by 2396 section 3.3 should map to the same resource as: http://www.myfirm.com/myapp/mycontext/mypage.jsp (just that the resource can return different content depending on the params). Of course, Tomcat doesn't handle this case correctly either. > I'd be fine with the change if it were made configurable: > e.g. add a const char *sep argument to the function. > > -- > Nick Kew >
