Develop Reference

How to fix tomcat org.apache.tomcat.util.http.parser.HttpParser.<clinit> Character [[] is not allowed and will continue to be rejected

There are characters [ and ] in my request URL, and project deployed on Tomcat8.5.33. Some exception happens when I post request.
20-Sep-2018 10:55:36.494 WARNING [http-nio-8075-exec-2] org.apache.tomcat.util.http.parser.HttpParser.<clinit> Character [[] is not allowed and will continue to be rejected.
20-Sep-2018 10:55:36.494 WARNING [http-nio-8075-exec-2] org.apache.tomcat.util.http.parser.HttpParser.<clinit> Character []] is not allowed and will continue to be rejected.
20-Sep-2018 10:56:07.083 INFO [http-nio-8075-exec-10] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:479)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:684)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

Tomcat8.5.33 doesn't allow special character in URL, like |{}[].
And there are two methods to avoid this error.
If your special character is one of |{}, you could add config conf\catalina.properties like below directly:
tomcat.util.http.parser.HttpParser.requestTargetAllow=|{}
If your special character are some others, you could config conf\server.xml like below:
<Connector port="8075" protocol="HTTP/1.1" relaxedQueryChars='|[]'
connectionTimeout="20000"
redirectPort="8443" />

There are characters [ and ] in my request URL ....
This is the real problem. You are sending your server a request with an invalid URL. A valid URL cannot contain [ and ] ... except in an IP literal in the host part. They must be %-escaped in all other cases.
The correct solution is to fix your URLs and/or the software that generates them on the client side.
Tomcat is simply enforcing the rules in the URL / URI specifications ... that have been in the spec for the last 20+ years or so.
Reference:
RFC3986 - Uniform Resource Identifier (URI): Generic Syntax

Java, Tomcat : AN invalid character was present in the cookie value

I am working a SPring-MVC project where I am trying to set the cookie. I am using Tomcat7, And I have already set the cookie processor in context.xml to Rfc6265CookieProcessor. Currently I am getting the following error.
Error log :
HTTP Status 500 - Request processing failed; nested exception is java.lang.IllegalArgumentException: An invalid character [44] was present in the Cookie value
type Exception report
message Request processing failed; nested exception is java.lang.IllegalArgumentException: An invalid character [44] was present in the Cookie value
description The server encountered an internal error that prevented it from fulfilling this request.
exception
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.IllegalArgumentException: An invalid character [44] was present in the Cookie value
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:979)
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:869)
javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:843)
javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
Cookie values to be set : The spaces are not actually there, got them while reformatting in IntelliJ to get them in one paragraph :
s.d774b7c6eabba92fce3edbed8a9b003b,
s.bdf5f951e4ab858aac87fb182439f57f,
s.e77bd0cd86b4af86c4a550ec11d71d4c,
s.431334e112350c9d545f7a44cbcc530d,
s.6e6057e5483b538cf9c6daf2934fd825,
s.ea2438094c8631123fab3bf3efb7ec17,
s.e17b1d9dd1b9702ca8c9e95d30906dd5, s .3f 3 c8f3fc19597025ef87dafc0fb277a, s .5531
b742d6e12717f4071818b5861bd2, s .420811998d
b14d0a68dd9e3d3c04849f, s.d8ed1aa3b0a2e513d449a96182898160, s.f3b5784d6e777032c6b7576e7d824af0, s .69
bc19557e43fcfa83816f427b60a09d, s .5677087e bc57003436c55f49fceff5cb, s .5f
a872b3e84fd69618534940034e1adb, s.fe4184c9b925ddf04def79c0c55392ca, s .74e4438d 05f 267
c48297a0c66a7dbeba, s .95e c071a356cf1998d809267006725db, s .9 b72a01cfda4509833c1f0c7bf2afdac, s .5240f
10897d 2f 96f 49d 0328 a2521519c, s .518 cd1d749fbba6540424874d64c5443

Character 44 (comma) is not valid in a cookie value.
See https://www.rfc-editor.org/rfc/rfc6265 for more details.

The solution for me was to change the version of Tomcat, I was working with 8.5 and I was getting the character error in cookie value, I changed to Tomcat 9 and the problem continued, finally with Tomcat 7 it was solved. The most logical option is to replace the commas in the cookie values, but if you want to quickly fix the problem locally and keep working you might consider switching from Tomcat.

Wildfly: org.xnio.channels.FixedLengthOverflowException

Until now we used JBoss AS 7.1 which has a tomcat as front-server. We now upgraded to Wildfly (JBoss 8.0) which ships with undertow as a tomcat replacement.
For our filedownloads, we are reading the input stream of the file, and writing this to the external context's response output stream. This worked well in JBoss AS 7.1 - even for large files. In Undertow WE receive the following exception even for pretty "small" files:
13:04:43,292 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /project/getFile.xhtml}: java.lang.RuntimeException: org.xnio.channels.FixedLengthOverflowException
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: org.xnio.channels.FixedLengthOverflowException
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:97)
at org.xnio.conduits.Conduits.writeFinalBasic(Conduits.java:132) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.writeFinal(AbstractFixedLengthStreamSinkConduit.java:137)
at org.xnio.conduits.ConduitStreamSinkChannel.writeFinal(ConduitStreamSinkChannel.java:104) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.channels.DetachableStreamSinkChannel.writeFinal(DetachableStreamSinkChannel.java:172)
at io.undertow.servlet.spec.ServletOutputStreamImpl.writeBufferBlocking(ServletOutputStreamImpl.java:580)
at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:614)
at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
... 9 more
The getFile.xhtml is invoking the download and the following code is used to copy the stream:
(Try, catch, logs and error handling removed to save some space)
public void downloadFile(FileEntity fileEntity) {
FacesContext fc = FacesContext.getCurrentInstance();
ExternalContext ec = fc.getExternalContext();
ec.responseReset();
ec.setResponseContentType(getMimeType(fileEntity.getFile()));
ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue());
ec.setResponseHeader("Content-Disposition", "attachment; filename=\"" + ConversionHelper.validateFilename(fileEntity.getDisplayFileName()) + "\"");
OutputStream output = ec.getResponseOutputStream();
FileInputStream fis = new FileInputStream(fileEntity.getFile());
IOUtils.copy(fis, output);
fc.responseComplete();
}
I noticed that removing the line
ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue());
makes it work again. However the ResponseConentLength is "correct". Using
ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue() + 9);
(note the +9) solves this. Using +8 -> FixedLengthOverflow, using +10 -> FixedLengthUnderflow
The +9 is independent of the filesize. Any idea? Looks strange to me...

If you call output.close() it should have the effect you are after. This looks like an issue with JSF, and not related to Undertow.

Found the problem.
It has to do with the change of the server engine. Just not sure if it is directly related to undertow, or more an error with wildfly / JSF (or if it was an error in Jboss and now is working correctly):
To invoke the download, we used something like this in the getFile.xhtml:
<f:metadata>
<f:viewParam name="fileId" required="true"
value="#{getFileController.fileId}"></f:viewParam>
</f:metadata>
<h:outputLabel value="#{getFileController.download()}" />
this would usually produce:
<label>value</label>
if the value of the label would be a string.
since we reset the response inside download(), <label> is removed again. Then, using a fixed response size that's equal the file-length and calling responseComplete() basically ommits the trailing </label>. Undertow however seems to ignore the responseComplete()-Call and tries to append </label> to the response, notices, that the end of the (fixed) response stream is reached, and therefore throws the mentioned exception.
That's why providing a size of +9 solves this error - but causes corrupt files, cause </label>\n will be appended to the file.
obviously the usage of an output label was bad practice there. But since we reseted and manually filled the response stream and called responseComplete() that was working fine.
the fix is obviously to not produce any (not required) html tags on that page:
<f:metadata>
<f:viewParam name="fileId" required="true"
value="#{getFileController.fileId}"></f:viewParam>
<f:event listener="#{getFileController.dlNow()}" type="preRenderView"></f:event>
</f:metadata>
Beside the bad design there - shouldn't call responseComplete() ommit any additional writing to the response stream, including any write ATTEMPTS?
The docu says:
Signal the JavaServer Faces implementation that the HTTP response for
this request has already been generated (such as an HTTP redirect),
and that the request processing lifecycle should be terminated as soon
as the current phase is completed.
So, if the Faces Implementation is told that the Response has been send - why would it try to append something?

WstxUnexpectedCharException: Unexpected character '"' (code 34) in DOCTYPE declaration; expected a space between public and system identifiers

I am trying to solve the below issue for last couple of days but still not able to resolve it. I have searched lots of forums but all in vain.
*Little bit of history: My code was working well in the devp env but for accessing the production sever I received new URL and three new certificates after successfully including the certificates in new trust store file.I am facing below issue. Please help.
2013-11-25 11:32:30,373 INFO[BuilderUtil] OMException in getSOAPBuilder
org.apache.axiom.om.OMException: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '"' (code 34) in DOCTYPE declaration; expected a space between public and system identifiers
at [row,col {unknown-source}]:[1,46]
at org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:296)
at org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.getSOAPEnvelope(StAXSOAPModelBuilder.java:198)
at org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.<init>(StAXSOAPModelBuilder.java:154)
at org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.<init>(StAXSOAPModelBuilder.java:140)
at org.apache.axis2.builder.BuilderUtil.getSOAPBuilder(BuilderUtil.java:686)
at org.apache.axis2.transport.TransportUtils.createDocumentElement(TransportUtils.java:197)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:145)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:108)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:67)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:354)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:421)
at org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run(OutInAxisOperation.java:446)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '"' (code 34) in DOCTYPE declaration; expected a space between public and system identifiers
at [row,col {unknown-source}]: [1,46]
at com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:648)
at com.ctc.wstx.sr.BasicStreamReader.startDTD(BasicStreamReader.java:2482)
at com.ctc.wstx.sr.BasicStreamReader.nextFromPrologBang(BasicStreamReader.java:2398)
at com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2058)
at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
at org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.next(XMLStreamReaderWrapper.java:225)
at org.apache.axiom.om.impl.builder.StAXOMBuilder.parserNext(StAXOMBuilder.java:668)
at org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:214)
... 14 more
2013-11-25 11:32:30,378 INFO [BuilderUtil] Remaining input stream :[]
2013-11-25 11:32:30,380 DEBUG [AuditUtilities] Request Message Id: urn:uuid:5f75a15c-ad57-4d00-b277-75fe7b1e241d
2013-11-25 11:32:30,380 DEBUG [AuditUtilities] Response Message Id: null
2013-11-25 11:32:30,380 DEBUG [AuditUtilities] Response Message Data: null
My SOAP request seems me correct:
<?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"><ns4:product xmlns:ns4="http://ns.electronichealth.net.au/hi/xsd/common/CommonCoreElements/3.0" soapenv:mustUnderstand="false"><ns4:vendor><ns1:qualifier xmlns:ns1="http://ns.electronichealth.net.au/hi/xsd/common/QualifiedIdentifier/3.0">http://ns.electronichealth.net.au/id/hi/vendorid/1.0</ns1:qualifier><ns1:id xmlns:ns1="http://ns.electronichealth.net.au/hi/xsd/common/QualifiedIdentifier/3.0">SDS</ns1:id></ns4:vendor><ns4:productName>HI</ns4:productName><ns4:productVersion>10.1</ns4:productVersion><ns4:platform>LINUX</ns4:platform></ns4:product><h:signature xmlns:h="http://ns.electronichealth.net.au/hi/xsd/common/CommonCoreElements/3.0"><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /><ds:Reference URI="#body-c3c18409-d0df-4aed-b294-87af248c61f0"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><ds:DigestValue>3pGWeWvyYHDdsDTu0F7qATI3Jp4=</ds:DigestValue></ds:Reference><ds:Reference URI="#timestamp-232e1ed9-f97a-4515-89bd-a3683fab0fce"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><ds:DigestValue>dGJxcKsX+y4jb0ndH1RQDqeWnTw=</ds:DigestValue></ds:Reference><ds:Reference URI="#user-69d4eead-8b69-4e0a-85d7-b2a58867aaa0"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><ds:DigestValue>9ET9aqC4jkINuYY8OhKsAJPEwX8=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>W24rpxUgpbTzxvJUoj5WpBsEssdaaddd56464t4eyYCAa2q9J0izrWIuukvOovde5h+xxxd1+5h/7JREGERGERGEGEGEGRTH5YT34R3EHYJGBDSEFERHJNFGGFFWEBzj7Jj3wfGs3WOLwsvhCuVBRY79mXTAxyQZYiUl7+tk3Pdm5YcSM0ZKfQJyUChIL1mjxALhwdCJkHOneJenjTgFaGRP+0iPF51TDc7l5ruxw8NdsSuN7P8D6lax3Fa4lck2iW/+t43yJ6cqTjZztMPuyKcYUgFhCS4334534234ERFGWBqyZhgRGFREGREG4543645FGER34WEFW4TERSygB8Gj+nx+217qRFTXD8/vcr8/BA1zWDLR05QdyZSDfuOfWTXpgfDcPTqedteeaww5cetv8L5J0dpFvRUkVDFGFGERcTOzmQALQZ+2C81RaNidKeQz++Q==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIF+zCCBOOgAwIBAgIDBWhPMA0GCSqGSIb3DQEBBQUAMH8xCzAJBgNVBAYTAkFVMQwwCgYDVQQKEwNHT1YxGzAZBgNVBAsTEk1lZGljYXJlIEF1c3RyYWxpYTFFMEMGA1UEAxM8VGVzdCBNZWRpY2FyZSBBdXN0cmFsaWEgT3JnYW5pc2F0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDswdwsEWRWER435433dwdwqedTEyMDQzMDAxNDI0MloXDTE3MDQzMDAxNDI0MFowgbUxCzAJBgNVBAYTAkFVMQwwCgYDVQQIEwNBQ1QxFDASBgNVBAcTC1RVR0dFUkFOT05HMSYwJAYDVQQKEx1UZXN0IExvY2F0aW9uIENlcnRpZmljYXRlIDAxOTEmMCQGA1UECxMdVGVzdCBMb2NhdGlvbiBDZXJ0aWZpY2F0ZSAwMTkxMjAwBgNVBAMTKVRlc3QgTG9jYXRpb24gQ2VydGlmaWNhdGUgMDE5IDo1OTU0Mzg3NjU5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArnQbZd3dOT+mpZIYU5x/jsREa+FTxO5RBDyusuZshR5se95qt9jMgJ+/g/ewzNBNpmPTfQtqLqbPnbQ1NCSmnAyM7nznHcRB+v2QeIJtgFLsBnx2zt/Q+ljgNBr8eNEZll8z8eX1fgrGjOQ0utXOWZ21N7DR6tH23zKC36yv/zAhRw/zWX2+FAaUS0TBxBkcXI4dTiC+5X00IiU7C4gGMGesd89Y8/KCZVj8JVinQQHF3hzYon7f7MctL/dN6Bp5UxtWh1nX/AliJMCrvoNUDo7D4yhtIPhjE/AwBr3+MkEBLoB4vEwHIKX790+BpPzlgast+D510NY1/1bcz65gFQIDAQABo4ICRzCCAkMwDAYDVR0TAQH/BAIwADAwBgNVHREEKTAngSV0ZXN0LmxvY2F0aW9uMDE5QGh1bWFuc2VydmljZXMuZ292LmF1ME8GCCsGAQUFBwEBBEMwQTA/BggrBgEFBQcwAYYzaHR0cDovL29jc3AuY2VydGlmaWNhdGVzLWF1c3RyYWxpYS5jb20uYXUvbWFvY2EucGt4MIIBIQYDVR0gBIIBGDCCARQwggEQBgoqJNL+gHcBBgECMIIBADCBywYIKwYBBQUHAgIwgb4agbtDZXJ0aWZpY2F0ZXMgaXNzdWVkIHVuZGVyIHRoaXMgQ1AgbXVzdCBvbmx5IGJlIHJlbGllZCBvbiBieSBlbnRpdGllcyB3aXRoaW4gdGhlIENvbW11bml0eSBvZiBJbnRlcmVzdCwgdW5sZXNzIG90aGVyd2lzZSBhZ3JlZWQsIGFuZCBub3QgZm9yIHB1cnBvc2VzIG90aGVyIHRoYW4gdGhvc2UgcGVybWl0dGVkIGJ5IHRoaXMgQ1AuMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3Lm1lZGljYXJlYXVzdHJhbGlhLmdvdi5hdS8wGQYJKiSjkJUXAc4ZBAwWCjU5NTQzODc2NTkwDgYDVR0PAQH/BAQDAgeAMBMGA1UdIwQMMAqACECvQwoiM+vJMDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9tYS10ZXN0LXBraS9NQU9DQUNSTHMvbGF0ZXN0LmNybDARBgNVHQ4ECgQITn3Ed1kIvoEwDQYJKoZIhvcNAQEFBQADggEBABq+Kl821YVzW8DE0xxLhjiD1CUDeqyrANQ0fszI83zedC2imcfvFoxPlZCpRLCmy434be22Flc0PDRCQcuZHa3sXj3PGsjpE2zhPP1sojD6riVR1ivu8CMh5XM+xiCsKwxIuXMWGUUm3xzNXv4VJ2fwk7Tpy+zmJbaxwu9ehyAcQpvJoirjicZ1qiapPFq4Y9qHecNOHt8Qe1fMrfmHJ2LxPvvTfNpX+VMYQsDGnhZ9yZgCXmi7+YfIk33605ddJGfzFh8Yp7PVAQtxbbHhSr+IqJTdpK8Tp/nPUJlzWZ1JKvWXRSzOH7OiuQVVda3tFUzPCCZ0El/ByIwwMmfDPy4=</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature></h:signature><ns4:timestamp xmlns:ns4="http://ns.electronichealth.net.au/hi/xsd/common/CommonCoreElements/3.0" xml:id="timestamp-232e1ed9-f97a-4515-89bd-a3683fab0fce"><ns4:created>2013-11-25T11:32:27.296+11:00</ns4:created><ns4:expires>2013-11-25T12:32:27.296+11:00</ns4:expires></ns4:timestamp><ns4:user xmlns:ns4="http://ns.electronichealth.net.au/hi/xsd/common/CommonCoreElements/3.0" xml:id="user-69d4eead-8b69-4e0a-85d7-b2a58867aaa0"><ns1:qualifier xmlns:ns1="http://ns.electronichealth.net.au/hi/xsd/common/QualifiedIdentifier/3.0">http://sdspathology.com.au/id/hi/userid/1.0</ns1:qualifier><ns1:id xmlns:ns1="http://ns.electronichealth.net.au/hi/xsd/common/QualifiedIdentifier/3.0">TEST_SDS_USER_ID</ns1:id></ns4:user><wsa:To>https://www3.medicareaustralia.gov.au/pcert/soap/services/</wsa:To><wsa:MessageID>urn:uuid:5f75a15c-ad57-4d00-b277-75fe7b1e241d</wsa:MessageID><wsa:Action>http://ns.electronichealth.net.au/hi/svc/ConsumerSearchIHIBatchAsync/3.0/ConsumerSearchIHIBatchAsyncPortType/submitSearchIHIBatchRequest</wsa:Action></soapenv:Header><soapenv:Body xml:id="body-c3c18409-d0df-4aed-b294-87af248c61f0"><ns12:submitSearchIHIBatch xmlns:ns12="http://ns.electronichealth.net.au/hi/svc/ConsumerSearchIHIBatchAsync/3.0"><ns12:searchIHIBatchRequest><searchIHI xmlns="http://ns.electronichealth.net.au/hi/xsd/consumermessages/SearchIHI/3.0"><s36:medicareCardNumber xmlns:s36="http://ns.electronichealth.net.au/hi/xsd/consumercore/ConsumerCoreElements/3.0">2950249651</s36:medicareCardNumber></searchIHI><ns11:requestIdentifier xmlns:ns11="http://ns.electronichealth.net.au/hi/xsd/consumermessages/SearchIHIBatch/3.0">d1f21610-6cb9-4e60-9673-18f43a4500b5</ns11:requestIdentifier></ns12:searchIHIBatchRequest></ns12:submitSearchIHIBatch></soapenv:Body></soapenv:Envelope>
Please suggest.

Had a very similar issue. The WSDL file is delivered, but calls on the bind address fail with this bogus doctype error. In our prod environment, http requests coming from outside the corporate network are swapped across to https. The solution was to request the WSDL file using https, then everything worked.

The problem is that the response is not XML, it is most likely a HTML page. In my case, the SOAP service I was requesting did not exist so I was getting a HTML error page, which starts like
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
There error is referring to that second-last character, the double quote.

I had a similar problem.
You should have a syntax error at line 46 in your wsdl file
[row,col {unknown-source}]:[1,46]

I had the same problem.
I always receive this error when the response of my request is an unexpected HTML. I usually receive this response when I call to a request (URI) that the server doesn`t know and go back a 404 error code.

I had the same error message, but that is also for XML attributes as..:
<add>
<doc>
<field name=id>48</field> <!-- Incorrect -->
<field name="id">48</field><!-- Correct -->
.....
</doc>
</add>

I had an ampersand symbol (&) in a table, and then I used Jira's Page Properties Report macro to show that content from that cell, and it was failing with a similar error.

Blank Page in JSF

If my code throws an exception, sometimes - not everytime - the jsf presents a blank page. I´m using facelets for layout.
A similar error were reported at this Sun forumn´s post, but without answers.
Anyone else with the same problem, or have a solution?
;)
Due to some requests. Here follow more datails:
web.xml
<error-page>
<exception-type>com.company.ApplicationResourceException</exception-type>
<location>/error.faces</location>
</error-page>
And the stack related to jsf is printed after the real exception:
####<Sep 23, 2008 5:42:55 PM GMT-03:00> <Error> <HTTP> <comp141> <AdminServer> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1222202575662> <BEA-101107> <[weblogic.servlet.internal.WebAppServletContext#6d46b9 - appName: 'ControlPanelEAR', name: 'ControlPanelWeb', context-path: '/Web'] Problem occurred while serving the error page.
javax.servlet.ServletException: viewId:/error.xhtml - View /error.xhtml could not be restored.
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:249)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:525)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:261)
at weblogic.servlet.internal.ForwardAction.run(ForwardAction.java:22)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.servlet.internal.ErrorManager.handleException(ErrorManager.java:144)
at weblogic.servlet.internal.WebAppServletContext.handleThrowableFromInvocation(WebAppServletContext.java:2201)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2053)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
javax.faces.application.ViewExpiredException: viewId:/error.xhtml - View /error.xhtml could not be restored.
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:180)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
I´m using the jsf version Mojarra 1.2_09, richfaces 3.2.1.GA and facelets 1.1.13.
Hope some help :(

I think this largely depends on your JSF implementation. I've heard that some will render blank screens.
The one we were using would throw error 500's with a stack trace. Other times out buttons wouldn't work without any error for the user. This was all during our development phase.
But the best advice I can give you is to catch the exceptions and log them in an error log so you have the stack trace for debugging later. For messages that we couldn't do anything about like a backend failing we would just add a fatal message to the FacesContext that gets displayed on the screen and log the stack trace.

I fixed a similar problem in my error.jsp page today. This won't be exactly the same as yours, but it might point someone in the right direction if they're having a similar problem. My problem seemed to be coming from two different sources.
First, the message exception property wasn't being set in some of the servlets that were throwing exceptions caught by the error page. The servlets were catching and rethrowing exceptions using the ServletException(Throwable rootCause) constructor.
Second, in the error page itself, the original author had used scriptlet code to parse the message using String.split(message, ";"); Since the message was null this failed. I was getting a NullPointerException in my error log, along with the message "Problem occurred while serving the error page."
These two things combined to give me a blank page at the URL of the servlet that was throwing the original exception. I fixed my problem by providing my own error message when I rethrow exceptions in my servlets using the ServletException(String message, Throwable rootCause) constructor, so the error message will no longer be null. I also rewrote the error.jsp page using EL instead of scriptlet code, but that wasn't strictly necessary.

For a blank page on JSF 2, place a breakpoint in ExceptionHandlerWrapper.handle or a class overriding this method. In my case it was due to custom code which was a too restrictive and the error was not logged.