[
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: [email protected]
For additional commands, e-mail: [email protected]
