On Thu, 2013-01-03 at 12:42 +0000, Husarik, Branko wrote: > Hello, > > I will try to clarify the process as I see it: > > Request message sending process from Oracle to Web Service > Oracle --> HTTP --> Tomcat --> Input/Output stream --> webapp --> > Input/Output stream --> Tomcat --> HTTPS --> Web Service > > Response message receiving process from Web Service to Oracle > Web Service--> HTTPS --> Tomcat --> Input/Output stream --> webapp --> > Input/Output stream --> Tomcat --> HTTP --> Oracle > > The problem occures during the receiving stage (Tomcat --> > Input/Output stream --> webapp) when the response from Web service > cointains "HTTP/1.1 500 Internal Server Error" > > Webapp modifies the message (for example it adds basic > authentication). I hope I don't miss something Big. >
Sounds like 'webapp' is what you referred to as the 'Proxy' in your
original message? And it sounds like it's the 'webapp' that's
discarding the SOAP response. Perhaps when it sees the 500 HTTP
response code it simply discards the body of the response and sends that
generic error message instead -- e.g. by calling sendError() and letting
Tomcat generate it's default error response or the webapp's error page
(if one is defined)?
Depending on which component you have control over you can either:
1. Modify the 'webapp' to unconditionally send back the response
body (perhaps by modifying it's error page if one is defined)
-- OR --
2. Modify the Web Service to reply with a 200 HTTP response code
even if the service request fails.
#2 seems the more reasonable approach to me since the failure is on the
service level not the HTTP level.
But in either case there's no tweaking in Tomcat itself that will fix
this.
> Braňko
>
> -----Original Message-----
> From: André Warnier [mailto:a...@ice-sa.com]
> Sent: 3. ledna 2013 11:23
> To: Tomcat Users List
> Subject: Re: Tomcat doesn't process error messages
>
> Husarik, Branko wrote:
> > SOAP service logic should manipulate the message, but there is need to
> > receive message from Tomcat by reading it's input stream. Problem is, there
> > is only error stream cointaining tomcat error coming from Tomcat. I think
> > it is caused by message from web service, which cointains " HTTP/1.1 500
> > Internal Server Error " in HTTP protocol and SOAP message is not forwarded.
> > It seems to me like common logic, but i don't know, how to set Tomcat to
> > forward these messages to input stream.
> >
> Hi.
> Personally, I do not understand what you are trying to say. I believe that
> there is some incorrect understanding on your part of how this is supposed to
> work.
>
> In the scenario as you describe it,
> - Oracle is the HTTP client for Tomcat (just like any browser could be a
> client)
> - inside Tomcat, runs some webapp which happens to be a SOAP proxy. What this
> webapp does, is unknown to Tomcat. As far as Tomcat is concerned, this
> webapp is supposed to process some HTTP requests (depending on the URL of the
> request), and generate a HTTP response.
> Schematically, we have this :
>
> request :
> Oracle client --> HTTP --> Tomcat --> webapp (--> ???? (unknown to Tomcat))
>
> response :
> ( ???? (unknown to Tomcat) --> ) webapp --> Tomcat --> HTTP --> Oracle client
>
> Repeat : what the webapp does inside is unknown and of (almost) no interest
> to Tomcat.
> (For example, if the webapp uses HTTPS to communicate with something else,
> Tomcat never knows this, and never plays any role in that part) So in this
> case, if the webapp generates a response which happens to be a 500 error,
> Tomcat will forward this to the (Oracle client). Tomcat will never read any
> "input stream coming back from the webapp" or anything like this.
> It is the webapp which is responsible for that kind of thing.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
signature.asc
Description: This is a digitally signed message part
