You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ji...@apache.org on 2008/08/18 18:10:42 UTC
svn commit: r686809 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
Author: jim
Date: Mon Aug 18 09:10:41 2008
New Revision: 686809
URL: http://svn.apache.org/viewvc?rev=686809&view=rev
Log:
Remove trailing path element, ala ./jk/native/common/jk_lb_worker.c,
but use apr_strtok niceness. PR: 45158
Modified:
httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c?rev=686809&r1=686808&r2=686809&view=diff
==============================================================================
--- httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c (original)
+++ httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c Mon Aug 18 09:10:41 2008
@@ -141,7 +141,7 @@
++path;
if (strlen(path)) {
char *q;
- path = apr_strtok(apr_pstrdup(pool, path), "?&", &q);
+ path = apr_strtok(apr_pstrdup(pool, path), ";?&", &q);
return path;
}
}
Re: svn commit: r686809 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
Posted by Nick Kew <ni...@webthing.com>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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" <ni...@webthing.com> 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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Different issue; different response.
>
> Bill Barker wrote:
>> "Nick Kew" <ni...@webthing.com> 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.
Re: svn commit: r686809 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Different issue; different response.
Bill Barker wrote:
> "Nick Kew" <ni...@webthing.com> 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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Bill Barker wrote:
>
> 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.
Just to be clear, the 2396 property foo=bar refers only to /myapp,
and not specifically /myapp/mycontext and has no bearing on
/myapp/mycontext/mypage.jsp. That's just a common Java misinterpretation,
and the reason httpd server doesn't specifically support ';' syntax (which
isn't to say it's not generally supported; /myapp is not /myapp;foo=bar).
Unless you can clarify for us what the distinction between;
http://www.myfirm.com/myapp;foo=bar/mycontext/mypage.jsp
http://www.myfirm.com/myapp/mycontext;foo=bar/mypage.jsp
http://www.myfirm.com/myapp/mycontext/mypage.jsp;foo=bar
which might lead me to believe that folks implemented 2396 purposefully.
Re: svn commit: r686809 - /httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
Posted by Bill Barker <wb...@wilshire.com>.
"Nick Kew" <ni...@webthing.com> wrote in message
news:48AADC3F.5070609@webthing.com...
> jim@apache.org 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
Posted by Nick Kew <ni...@webthing.com>.
jim@apache.org 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