You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "Jeffrey Bennett (JIRA)" <xe...@xml.apache.org> on 2010/03/15 03:57:27 UTC
[jira] Created: (XERCESJ-1425) Read timed out error when
TrailingMiscDispatcher encounters garbage
Read timed out error when TrailingMiscDispatcher encounters garbage
-------------------------------------------------------------------
Key: XERCESJ-1425
URL: https://issues.apache.org/jira/browse/XERCESJ-1425
Project: Xerces2-J
Issue Type: Bug
Affects Versions: 2.9.1
Environment: Xerces 2.9.1 as utilized from Axis 1.4 within a webservice environment (on Tomcat 5.5)
Reporter: Jeffrey Bennett
Our webapp (running within Tomcat) was making a SOAP call to a remote host over an SSL connection (our webapp is the client in this transaction). We got a response back with a legitimate SOAP-ENV. However, following the close of the SOAP-ENV (after </SOAP-ENV>) there was some additional random characters. Specifically, this is what came back (ignoring the quote marks):
"</SOAP-ENV:Body></SOAP-ENV:Envelope>.b>..,...<....&."
Not entirely sure why we got those extra 16 characters. Could have been bad-behavior by the remote server. Or could be some artifact of the SSL. Can't say, but beyond the control of the client, so we're forced to deal with them.
Xerces manages those characters by sending them to TrailingMiscDispatcher. Down in the bowels of that code, it winds up doing a read() call that opens a socket (to somewhere, not sure where though). That read() never returns and the net effect is that the parse() of the entire SOAP message times out. I was able to overcome this timeout by forcing TrailingMiscDispatcher.dispatch(..) to return false.
I would propose that Xerces maintain the current behavior (as the default). However, it should check a (system?) property, and if the property is set, trailing-misc would be ignored. The upshot of this would be that rather than the brute force approach I was forced into, I could simply set a property so that trailing garbage on my soap message would be ignored.
FWIW, I found that there are others affected by similar issues:
http://designdevelopment.digitalpoints.info/getting-timeout-after-receiving-response-from-web-service/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
[jira] Resolved: (XERCESJ-1425) Read timed out error when
TrailingMiscDispatcher encounters garbage
Posted by "Michael Glavassevich (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESJ-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Glavassevich resolved XERCESJ-1425.
-------------------------------------------
Resolution: Invalid
Sorry, while there may be a problem with the InputStream that you're using (which is timing out) this is a not a bug in Xerces. All XML parsers are required (by the XML 1.0 specification) to check the well-formedness [1] of XML documents and report violations as fatal errors, including those which occur in the trailing misc [2]. Xerces needs to read to the end of the stream to make this determination but has no control over what occurs beneath the calls to InputStream.read(). Issues with the I/O layer need to be addressed at that level. Xerces cannot work around them.
[1] http://www.w3.org/TR/2008/REC-xml-20081126/#sec-well-formed
[2] http://www.w3.org/TR/2008/REC-xml-20081126/#NT-Misc
> Read timed out error when TrailingMiscDispatcher encounters garbage
> -------------------------------------------------------------------
>
> Key: XERCESJ-1425
> URL: https://issues.apache.org/jira/browse/XERCESJ-1425
> Project: Xerces2-J
> Issue Type: Bug
> Affects Versions: 2.9.1
> Environment: Xerces 2.9.1 as utilized from Axis 1.4 within a webservice environment (on Tomcat 5.5)
> Reporter: Jeffrey Bennett
>
> Our webapp (running within Tomcat) was making a SOAP call to a remote host over an SSL connection (our webapp is the client in this transaction). We got a response back with a legitimate SOAP-ENV. However, following the close of the SOAP-ENV (after </SOAP-ENV>) there was some additional random characters. Specifically, this is what came back (ignoring the quote marks):
> "</SOAP-ENV:Body></SOAP-ENV:Envelope>.b>..,...<....&."
> Not entirely sure why we got those extra 16 characters. Could have been bad-behavior by the remote server. Or could be some artifact of the SSL. Can't say, but beyond the control of the client, so we're forced to deal with them.
> Xerces manages those characters by sending them to TrailingMiscDispatcher. Down in the bowels of that code, it winds up doing a read() call that opens a socket (to somewhere, not sure where though). That read() never returns and the net effect is that the parse() of the entire SOAP message times out. I was able to overcome this timeout by forcing TrailingMiscDispatcher.dispatch(..) to return false.
> I would propose that Xerces maintain the current behavior (as the default). However, it should check a (system?) property, and if the property is set, trailing-misc would be ignored. The upshot of this would be that rather than the brute force approach I was forced into, I could simply set a property so that trailing garbage on my soap message would be ignored.
> FWIW, I found that there are others affected by similar issues:
> http://designdevelopment.digitalpoints.info/getting-timeout-after-receiving-response-from-web-service/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org