Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
0.95
-
None
Description
In AXIS2C-380 I mentioned that although Apache httpd and mod_axis2 allow you to
customize the URL location where Web Services will be provided, in Axis2/C itself
this URL prefix is hard-coded. For example, with mod_axis2 you might do, in httpd.conf:
<Location /my/services/here>
SetHandler axis2_module
</Location>
There are several problems here. The main one is that several files in modules/core/engine
call the single function in util/src/utils.c and to "parse" the request's URL. However, this
function just scans for the hard-coded string "/services" – so it's going to fail in this case
because the "/services" in httpd's <Location> will match "too early". If the <Location> is
something like /foo, it won't match at all.
Also, even if the <Location> is for /axis2/services, if the incoming request is for the URL
/axis2//services//foo//bar, the extra slashes mean it won't match.
The attached patch attempts to take care of all these issues by centralizing a lot of the
parse code into modules/core/context/msg_ctx.c and by rewriting util/src/utils.c to use
the axis2_uri_t functions. A new parameter in axis2.xml is introduced, "requestURLPrefix",
which the administrator should set to whatever matches their httpd <Location>.
This still isn't ideal because really we should match against only what is in the
<Location> directive, and if multiple <Location>s were defined with the axis2_module
handler, they should all work. Having just a single matching parameter in axis2.xml
won't fix this. But, it's a start, I think, and if someone can improve it, go for it! Thanks!