Re: svn commit: r686809 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
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?
Re: svn commit: r686809 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
On 21 Aug 2008, at 13:39, Jim Jagielski wrote: 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? +1. (assuming I understand your meaning aright) -- Nick Kew
Re: svn commit: r686809 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
[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) 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
Re: svn commit: r686809 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
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
Re: svn commit: r686809 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
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. No, reserved characters are ***perfectly acceptable*** in the uri without escaping; c.v. 2. URI Characters and Escape Sequences URI consist of a restricted set of characters, primarily chosen to aid transcribability and usability both in computer systems and in non-computer communications. Characters used conventionally as delimiters around URI were excluded. The restricted set of characters consists of digits, letters, and a few graphic symbols were chosen from those common to most of the character encodings and input facilities available to Internet users. uric = reserved | unreserved | escaped ... reserved= ; | / | ? | : | @ | | = | + | $ | , ... unreserved = alphanum | mark mark= - | _ | . | ! | ~ | * | ' | ( | )
Re: svn commit: r686809 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
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.
