axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Molettiere <pie...@axonstudios.net>
Subject Re: Patch: fix for firewall issue
Date Fri, 23 Jul 2004 15:39:38 GMT

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:


Mime
View raw message