I'm using jax-rs on glassfish 3.1.2 and plan to migrate to glassfish 4.1. But after doing some tests I discovered that one of our client apps sends http request with two 'Content-type' strings:
PUT /api/v4/topTen HTTP/1.1\r\n
Content-Type: application/json\r\n
Content-Length: 5105\r\n
Host: 10.19.76.2:8080\r\n
User-Agent: Apache-HttpClient 1.0\r\n
Accept: application/json\r\n
Content-Type: application/json; charset=utf-8\r\n
The problem is that glasshfish 4.1 does not accept this request and answers with '400 Bad request', but glassfish 3.1.2 processes it perfectly.
Unfortunately I can't change the the client because it was published and many people use it.
Is there any way to tune 4.1 to accept such request and process it?
Try with adding content-length in your request header.
Related
We have created a JAX-WS webservice, this service is being invoked by multiple clients. Some clients have configured timeout for API response. Even after sending success response, some client are stating that request is being timed out.
So is there any way to track, at what time a particular request hits the server and what time server responded back ?
I've enable http traces in weblogic server by using below properties
-Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true
-Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true
And request and response are appearing like below, where timestamp is missing
---[HTTP request - ]---
Accept: text/xml, multipart/related
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
---[HTTP response 200]---
null: HTTP/1.1 200 OK
Content-Length: 521
Content-Type: text/xml;charset=UTF-8
Weblogic Version is - 12.2.1
I have a following scenario:
Oracle Web Service consumer procedure
Web Service gateway implemented using JAX-WS (runs in TomEE 1.7.2)
External Web Service
External web service is secured using HTTPS, but for testing purposes also has an unsecured version.
(1) and (2) interact over http
(2) and (3) interact over https
and for testing purposes (2) and (3) can be set to use http.
(1) consumes http version without any problem, but when we switch to secured channel, oracle (utl_http.get_response method) complains about http protocol error. SoapUI doesnt have any problems, reads soap response.
Here is the HTTP Response headers in SoapUI:
HTTP/1.1 200 OK
Connection: keep-alive
Date: Fri
Date: 27 Nov 2015 05:31:38 GMT
Server: nginx/1.2.6
Transfer-Encoding: chunked
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.2.2 Java/Oracle Corporation/1.7)
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
I am guessing the problem is in duplicate "Transfer-Encoding" header, as it might get appended to the first like "chucked, chunked" and oracle might not be smart enough :D to parse it.
Anyone has experienced this kind of a problem? Any suggestions?
Run in comments if you want more details to be able to help.
Thanks in advance!
I've upgraded from rich faces 3.3 to rich faces 4.2 because ajax didn't work for IE9. Now it still not works.
After receiving the Response IE gets an JS error "SCRIPT58734: Der Vorgang konnte aufgrund des folgenden Fehlers nicht fortgesetzt werden: c00ce56e." while trying
data.responseText=request.responseText
on jsf.js.html?ln=javax.faces&conversationContext=2, Line 1 Row 21747
I think it's because of an incorrecct HTTP header
Content-Type: text/xml;charset=UTF8
should be
Content-Type: text/xml;charset=UTF-8
Here The raw-response of the server
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: JSF/2.0
Cache-Control: no-cache
Content-Type: text/xml;charset=UTF8
Content-Length: 293
Date: Tue, 17 Apr 2012 15:25:22 GMT
<?xml version='1.0' encoding='UTF8'?>
<partial-response><changes><update id="outtest"><![CDATA[<span id="outtest"><span class="outhello">Hello !</span></span>]]></update><update id="javax.faces.ViewState"><![CDATA[2809980525147413088:295565165947012503]]></update></changes></partial-response>
i'm usinng
javaee-web-api 6
myfaces-orchestra-core 1.4
Hibernate 4.1
Spring 3.1.1
Richfaces 4.2.0
Primefaces 3.2
jsf-api+impl 2.1.7
jstl 1.2
and running on tomcat 7
EDIT:
of now i'm sure its the header. I set a breakpoint in charles-proxy and edited the response header manually, with the edited http header IE9 showed the right result without any errors
Your analysis is correct. The charset attribute in the Content-Type header is wrong and IE9 chokes on that with error c00ce56e.
JSF uses by default the one as obtained from ServletRequest#getCharacterEncoding(). This normally defaults to the client-specified one, or null if there's none (which is often the case). This is normally overrideable by some custom filter which calls request.setCharacterEncoding().
Given the incorrect charset, this can only mean that your web application is somewhere calling request.setCharacterEncoding() with "UTF8" instead of "UTF-8".
I'd start checking all filters and their configuration.
i got similar error but the problem was with the response headers content length. We had 24kb of data on the request header and we have to reduce it to half. That fixed the issue. i hope this helps someone.
I am getting this Error is java.io.IOException: Server returned HTTP response code: 500 for URL: exception while invoking the web service url that i have.
I am calling a .NET based web service through a framework built in java and getting:
Headers returned from the server:
Content-Length:736
Content-Type:text/xml; charset=utf-8
Server:Microsoft-IIS/7.0
X-Powered-By:ASP.NET
Date:Thu, 12 May 2011 08:51:45 GMT
java.io.IOException: Server returned HTTP response code: 500 for URL: "http://hcd
cd-bt01.hcch.com/HCCExceptionLogService/service.svc?wsdl"
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLCon
nection.java:1170)
at com.splwg.mpl.senders.http.HTTPSender.sendResponse(HTTPSender.java:34
5)
at com.splwg.mpl.sending.NewSenderManager.sendResponse(NewSenderManager.
java:191)
at com.splwg.mpl.sending.SameThreadSendingManager.callSender(SameThreadS
endingManager.java:63)
at com.splwg.mpl.stagingtable.download.OutboundMessageSender.handleRouti
ngs(OutboundMessageSender.java:361)
at com.splwg.mpl.stagingtable.download.OutboundMessageSender.sendRespons
e(OutboundMessageSender.java:95)
at com.splwg.mpl.sending.NewSenderManager.sendResponse(NewSenderManager.
java:191)
at com.splwg.mpl.sending.SameThreadSendingManager.processDestination(Sam
eThreadSendingManager.java:293)
at com.splwg.mpl.sending.SameThreadSendingManager.sendResponse(SameThrea
dSendingManager.java:252)
at com.splwg.mpl.sending.SameThreadSendingManager.doSend(SameThreadSendi
ngManager.java:208)
at com.splwg.mpl.server.async.ExecSendRequestProcessor.ProcessRequest(Ex
ecSendRequestProcessor.java:61)
at com.splwg.mpl.server.async.RequestProcessingThreadAdapter.run(Request
ProcessingThreadAdapter.java:46)
at com.splwg.mpl.server.PooledThread.run(PooledThread.java:91)
at java.lang.Thread.run(Thread.java:595)
The wsdl url which i am invoking is http://hcdcdbt01.hcch.com/HCCExceptionLogService/service.svc?wsdl
I have used SOAP UI 3.6.1 tool for testing this wsdl which is giving me the right result.
Headers that i have used are:
Content-Type: text/xml;charset=UTF-8
SOAPAction: "http://tempuri.org/IExceptionLogService/LogException"
POST
Host:hcdcd-bt01.hcch.com
http://hcdcd-bt01.hcch.com/HCCExceptionLogService/service.svc
SOAP UI HEADERS:
POST http://hcdcd-bt01.hcch.com/HCCExceptionLogService/service.svc HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: "http://tempuri.org/IExceptionLogService/LogException"
User-Agent: Jakarta Commons-HttpClient/3.1
Host: hcdcd-bt01.hcch.com
Content-Length: 763
Can any body tell me what went wrong ?
It is a server error response, presumably on an internal service as the given address doesn't reside on the internet AFAIK.
You must get the server logs to establish what it does not like about your request.
Since the server sent the response code 500 - internal server error - I think you'll have to debug it on the server side, not the client side.
You should check the output of the server log.
I'm watching CXF service traffic using DonsProxy, and the CXF client sends an HTTP header "SoapCompressed":
HttpHeadSubscriber starting...
Sender is CLIENT at 127.0.0.1:2680
Packet ID:0-1
POST /yada/yada HTTP/1.1
Content-Type: text/xml; charset=UTF-8
SoapCompressed: true
Accept-Encoding: gzip,gzip;q=1.0, identity; q=0.5, *;q=0
SOAPAction: ""
Accept: */*
User-Agent: Apache CXF 2.2
Cache-Control: no-cache
Pragma: no-cache
Host: localhost:9090
Connection: keep-alive
Transfer-Encoding: chunked
I'd like to turn SoapCompressed off in my dev environment so that I can see the SOAP on the wire. I've searched Google and grepped the CXF source code, but don't see anything in the docs or code that reference this. Any idea how to make the client send "SoapCompressed: off" instead, without routing it through Apache HTTPD or the like? Is there a way to configure it at the CXF client, in other words?
A grep of the CXF codebase doesn't yield "SoapCompressed" at all. I really don't think it's CXF that is sending that. The Accept-Encoding thing is also suspect as that is only sent if you enable the GZIP interceptors. Is it possible that the proxy thing you are using is adding it?
The client for org.apache.cxf.jaxrs.client.AbstractClient has points where you set the headers in a key-value map (Map). "SoapCompressed", "false".