[
http://issues.apache.org/jira/browse/AXIS-1999?page=comments#action_66580 ]
Jason Sweeney commented on AXIS-1999:
-------------------------------------
This is my suggestion for the patch explained above. All changes are in the
org.apache.axis.transport.http.AxisServlet class.
Header, line 110:
// Location of the services as defined by the servlet-mapping in web.xml
public static final String INIT_PROPERTY_SERVICES_PATH =
"axis.servicesPath";
>>> // This will enforce the use of the SOAPAction HTTP header as mandated by
>>> the SOAP HTTP binding
>>> // See: http://issues.apache.org/jira/browse/AXIS-1999
>>> public static final String REQUIRE_SOAP_ACTION_HEADER =
>>> "axis.requireSOAPActionHeader";
// These have default values.
private String transportName;
Header, line 138:
/**
* Should we turn off the list of services when we receive a GET
* at the servlet root?
*/
private boolean disableServicesList = false;
>>> /**
>>> * This will enforce the use of the SOAPAction HTTP header as mandated by
>>> the SOAP HTTP binding
>>> * For several legacy systems, providing a custom HTTP header is difficult
>>> or impossible.
>>> * Since this is more of a technicality and no actual value is required in
>>> the header,
>>> * allowing the header to be optional by configuration enables legacy
>>> systems to send SOAP
>>> * documents to an application exposing services through the Axis framework.
>>> * See: http://issues.apache.org/jira/browse/AXIS-1999
>>> */
>>> private boolean requireSOAPActionHeader = true;
/**
* Cached path to JWS output directory
*/
private String jwsClassDir = null;
protected String getJWSClassDir() {return jwsClassDir;
}
init(), line 184:
servicesPath = getOption(context, INIT_PROPERTY_SERVICES_PATH,
"/services/");
>>> // This will enforce the use of the SOAPAction HTTP header as mandated
>>> by the SOAP HTTP binding
>>> // See: http://issues.apache.org/jira/browse/AXIS-1999
>>> requireSOAPActionHeader = JavaUtils.isTrue(getOption(context,
>>> REQUIRE_SOAP_ACTION_HEADER, "true"));
getSoapAction(), line 992
private String getSoapAction(HttpServletRequest req) throws AxisFault {
String soapAction = req.getHeader(HTTPConstants.HEADER_SOAP_ACTION);
if (isDebug) {
log.debug("HEADER_SOAP_ACTION:" + soapAction);
/**
* Technically, if we don't find this header, we should probably
fault.
* It's required in the SOAP HTTP binding.
*/
}
>>> // This will enforce the use of the SOAPAction HTTP header
>>> // as mandated by the SOAP HTTP binding
>>> // See: http://issues.apache.org/jira/browse/AXIS-1999
if (soapAction == null) {
>>>
>>> if (requireSOAPActionHeader) {
AxisFault af = new AxisFault("Client.NoSOAPAction",
Messages.getMessage("noHeader00",
"SOAPAction"),
null, null);
exceptionLog.error(Messages.getMessage("genFault00"), af);
throw af;
>>> }
>>> else {
>>> // Simply set the SOAP Action to the empty value
>>> soapAction = "\"\"";
>>> }
}
// the SOAP 1.1 spec & WS-I 1.0 says:
// soapaction = "SOAPAction" ":" [ <"> URI-reference <"> ]
// some implementations leave off the quotes
// we strip them if they are present
if (soapAction.startsWith("\"") && soapAction.endsWith("\"")
&& soapAction.length() >= 2) {
int end = soapAction.length() - 1;
soapAction = soapAction.substring(1, end);
}
if (soapAction.length() == 0) {
soapAction = req.getContextPath(); // Is this right?
}
return soapAction;
}
> Add configuration setting to bypass the SOAP HTTP binding requirement of a
> SOAPAction header
> --------------------------------------------------------------------------------------------
>
> Key: AXIS-1999
> URL: http://issues.apache.org/jira/browse/AXIS-1999
> Project: Axis
> Type: Improvement
> Components: Basic Architecture
> Versions: 1.2
> Environment: Irrelevant to this issue
> Reporter: Jason Sweeney
>
> In the org.apache.axis.transport.http.AxisServlet.getSoapAction() method,
> when no HTTP header is found for the name 'SOAPAction' (as defined in
> org.apache.axis.transport.http.HTTPConstants.HEADER_SOAP_ACTION), the process
> faults and returns an error. As you mention very clearly in the
> documentation of this method, this is "technically" correct and respects the
> letter of the SOAP HTTP binding specification.
> However, in the real world, there are numerous applications that would and
> could communication SOAP message to an application exposing "web services"
> with Axis but that cannot configure custom HTTP headers (usually because the
> protocol management is encapsulated in an external library that never
> envisionned this possibility). Since by everyone's admission this is really
> a technicality of the specification and in real life almost no web services
> implementations actually use the value of the SOAPAction header to set the
> service name information, we would like the next version of Axis to offer a
> configuration setting to ignore this requirement of the SOAP HTTP binding
> specification.
> A proposal would be to include a new global parameter named
> 'axis.requireSOAPActionHeader' that would default to 'true', hence preserving
> the exact functional behavior of the current version. However, when set to
> false, the fault code of the getSoapAction() method mentioned above would be
> simply skipped and the value associated to the SOAPAction header would be
> left to 'null'.
> This simple configuration setting would allow many new business uses of the
> Axis framework and extremely simply the incremental migration of the
> interaction of legacy systems with new modern web service based systems.
> Thanks!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
