You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Peter Molettiere <pi...@axonstudios.net> on 2004/07/23 01:28:55 UTC
Patch: fix for firewall issue
I don't know if you guys are interested in this patch at all or not,
but here it is for what it's worth.
Some of our customers have run into issues with firewall settings
preventing our application from working when the firewall is set to
disallow unknown HTTP headers. These unknown headers include the
SOAPAction header, which for our application is always an empty string.
If the header is missing however, AxisServlet throws an AxisFault and
our application comes to a screeching halt.
To fix this issue, I'm modified AxisServlet to check a system property:
axis.useStrictHeaders. If that header is set to "false" then the
SOAPAction header will be set to an empty string if it isn't found in
the request. If the header exists, or if the system property is not set
to "false", then AxisServlet behaves as it ever did.
Here's a patch against AxisServlet:
==== ws-axis/java/src/org/apache/axis/transport/http/AxisServlet.java
====
951,954c951,959
< AxisFault af = new AxisFault("Client.NoSOAPAction",
<
Messages.getMessage("noHeader00",
<
"SOAPAction"),
< null, null);
---
> String strict =
System.getProperty("axis.useStrictHeaders");
>
> if("false".equals(strict)) {
> soapAction = "";
> } else {
> AxisFault af = new AxisFault("Client.NoSOAPAction",
> Messages.getMessage("noHeader00",
> "SOAPAction"),
> null, null);
956c961
< exceptionLog.error(Messages.getMessage("genFault00"), af);
---
> exceptionLog.error(Messages.getMessage("genFault00"),
af);
958c963,964
< throw af;
---
> throw af;
> }
959a966
>
Re: Patch: fix for firewall issue
Posted by Peter Molettiere <pi...@axonstudios.net>.
It's the watchguard firebox series firewalls -- they just strip the
unknown headers, but they allow the rest of the request through. Look
here: http://watchguard.com/ -- they have an HTTP proxy setting which
doesn't require you to actually set your clients to use their box as a
proxy, it just notices the outgoing connections and strips the headers
it doesn't know about.
As far as SOAPAction being mandatory, sure... conform to the spec.
However, it's not being used in our case. Ever. I'd guess that there's
a whole class of users of axis whose applications are similar. So I
don't see any problem with ignoring it if it's missing, especially if
there's a special configuration option to specify non-standard
behavior. Your concerns are of course broader than mine, so feel free
to use (or not) this patch as you see fit.
I'm not really aware of what the normal axis configuration mechanism
is... I thought it was via system properties. Feel free to modify as
you'd like to suit yourselves.
--Peter
On Jul 23, 2004, at 1:45 AM, Steve Loughran wrote:
> Peter Molettiere wrote:
>> I don't know if you guys are interested in this patch at all or not,
>> but here it is for what it's worth.
>> Some of our customers have run into issues with firewall settings
>> preventing our application from working when the firewall is set to
>> disallow unknown HTTP headers. These unknown headers include the
>> SOAPAction header, which for our application is always an empty
>> string. If the header is missing however, AxisServlet throws an
>> AxisFault and our application comes to a screeching halt.
>
> This interesting. Firewalls that disallow unknown http headers. Do
> they just strip them? Or reject the call?
>
> Whose firewall is this?
>
>
> I would have to check up on the specifications, but as I recall,
> SOAPAction is essentially mandatory in SOAP/WS-I. By hacking the
> server to ignore missing calls,
> you are working round the immediate problem, but the problem is still
> there and it will surface again, and again, and again.
>
> Maybe this is something we should refer to the soapbuilders, to see
> what the cross-toolkit consensus is.
>
>
>
>> To fix this issue, I'm modified AxisServlet to check a system
>> property: axis.useStrictHeaders. If that header is set to "false"
>> then the SOAPAction header will be set to an empty string if it isn't
>> found in the request. If the header exists, or if the system property
>> is not set to "false", then AxisServlet behaves as it ever did.
>
> If we were going to have this patch, it should be through the normal
> axis configuration mechanism,
> not system properties.
>
>
> -steve
>> Here's a patch against AxisServlet:
Re: Patch: fix for firewall issue
Posted by Steve Loughran <st...@apache.org>.
Peter Molettiere wrote:
>
> I don't know if you guys are interested in this patch at all or not, but
> here it is for what it's worth.
>
> Some of our customers have run into issues with firewall settings
> preventing our application from working when the firewall is set to
> disallow unknown HTTP headers. These unknown headers include the
> SOAPAction header, which for our application is always an empty string.
> If the header is missing however, AxisServlet throws an AxisFault and
> our application comes to a screeching halt.
This interesting. Firewalls that disallow unknown http headers. Do they
just strip them? Or reject the call?
Whose firewall is this?
I would have to check up on the specifications, but as I recall,
SOAPAction is essentially mandatory in SOAP/WS-I. By hacking the server
to ignore missing calls,
you are working round the immediate problem, but the problem is still
there and it will surface again, and again, and again.
Maybe this is something we should refer to the soapbuilders, to see what
the cross-toolkit consensus is.
>
> To fix this issue, I'm modified AxisServlet to check a system property:
> axis.useStrictHeaders. If that header is set to "false" then the
> SOAPAction header will be set to an empty string if it isn't found in
> the request. If the header exists, or if the system property is not set
> to "false", then AxisServlet behaves as it ever did.
If we were going to have this patch, it should be through the normal
axis configuration mechanism,
not system properties.
-steve
> Here's a patch against AxisServlet:
>