Incoming request contain next Content-Type:
Content-type: application/soap+xml; charset=UTF-8; action="testAction"
In JBoss 5.1 works very well, in WildFly 8.2 server answers with error "The given SOAPAction testAction does not match an operation."
If action="urn:testAction" then it works both - JBoss and WildFly.
How can I add "urn:" prefix to action on server side? I have added SOAPHandler and tried to change in SOAPMessageContext, but it read only (values not changed on update), in SOAPMessage I didnt found anything that would be worth to change.
Related
Is there a possibility to force tomcat to ignore "Expect" header or to use only HTTP 1.0?
I am sending curl request curl POST -vv 'http://127.0.0.1:8080/test' -d "#requests/test.xml" -H "SOAPAction: abc/test" -H "Content-Type: text/xml; charset=UTF-8" and curl adds by default "Expect" header which causes server waits for another request which never come.
Tech stack: Springboot 2.1.3.RELEASE, Tomcat 9.0.16
I cannot modify clients and to their requests empty header "Expect:".
I don't think there is a way to get Tomcat to respond only with an HTTP 1.0 response. That would be a protocol violation. If server gets an HTTP 1.1 request it must either respond with a HTTP 1.1 compatible response, or signal that it can't with a 505 HTTP Version Not Supported error.
Likewise, I don't think there is a way to get Tomcat to ignore a (well-formed / non-empty) Expect header. That would also be a protocol violation.
(While it is possible in theory for a server to violate the spec, I couldn't find a way to configure Tomcat to do that. Obviously you could download the Tomcat source code and modify it, but then you have the problem of maintaining your "fork".)
So what are the alternatives:
The HTTP spec says that server must ignore an Expect header in an HTTP 1.0 request. So you could add the --http1.0 option to the curl command.
The curl command uses a defaults file - ~/.curlrc - to get default overrides for various things. You could add an empty default for the Expect header into this file; see How to setup default "Expect" header for curl.
However, I think you may be worried unduly:
If you are worried that this will slow up the client (curl), don't. By default it only waits for 1 second for the 100 Continue response. (And I don't think that is what you are talking about ...)
If you are worried that this might tie up server side resources (in Tomcat), I can't see how that could be significant. The Tomcat server will timeout and close a client connection if there is no activity. This should deal with a curl command that sends the initial request but doesn't follow up.
I am using Mule 3.4.0 and am making a flow that calls some RESTful API endpoints on a JIRA server using an HTTPS outbound endpoint. I am having a problem because Mule is for some reason sending a Content-Type header value that causes an exception in JIRA. It looks like, judging from the JIRA stack trace, that Mule is sending this:
application/json, application/json;charset=UTF-8
JIRA is using Jersey and Jersey is unable to parse that Content-Type value. Here is a portion of the stack trace returned by JIRA:
Caused by: java.lang.IllegalArgumentException: Error parsing media type 'application/json, application/json;charset=UTF-8'
at com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:79)
at com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:53)
at javax.ws.rs.core.MediaType.valueOf(MediaType.java:119)
at com.sun.jersey.server.impl.model.HttpHelper.getContentType(HttpHelper.java:89)
... 157 more
Caused by: java.text.ParseException: Expected separator ';' instead of ','
at com.sun.jersey.core.header.reader.HttpHeaderReader.nextSeparator(HttpHeaderReader.java:117)
at com.sun.jersey.core.header.reader.HttpHeaderReader.readParameters(HttpHeaderReader.java:239)
at com.sun.jersey.core.impl.provider.header.MediaTypeProvider.valueOf(MediaTypeProvider.java:97)
at com.sun.jersey.core.impl.provider.header.MediaTypeProvider.fromString(MediaTypeProvider.java:77)
I would like to be able to force a specific Content-Type value to be sent, but I can't figure out how to do that. It seems like Mule automatically builds the Content-Type value based on a combination of factors:
http://www.mulesoft.org/documentation/display/current/HTTP+Transport+Reference
If the endpoint has encoding set explicitly, use that
Otherwise, take it from the message's property Content-Type
If none of these is set, use the Mule Context's configuration default.
For Content-Type, send the message's property Content-Type but with the actual encoding set.
So I think it's using the inbound property Content-Type, but since that's an inbound property I don't think I can modify/delete that in the flow. My attempts to modify/delete the Content-Type property have been ineffective. I can only modify/delete the outbound Content-Type property, which doesn't seem to help with my outbound HTTP request.
Any info on how to control the Content-Type value or fix it or something would be appreciated.
I spent some more time using debugging and breakpoints and discovered that, after the first HTTPS outbound endpoint, a "Content-Type" variable (NOT an inbound or outbound property) was being set, to "application/json". I have no idea why that was happening. I didn't see anything in the docs about that, either for HTTP Transport or HTTP Endpoint. If anybody can point out documentation around what is going on there that would be great.
As an experiment, before my next HTTPS outbound endpoint, I added a Variable transformer to delete the "Content-Type" variable. That fixed the problem!
So it seems like Mule was for some reason combining the "Content-Type" variable with the Content-Type value that I was specifying in the HTTP outbound endpoint, resulting in "application/json, application/json; charset=UTF-8".
I wound up having to put this after every HTTPS outbound endpoint to keep deleting the variable:
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.
I have a SOAP client sending through a request with it's Content-Type defined as application/x-www-form-urlencoded. My jax-ws server responds with a HTTP 415 error complaining that it expects a content-type of text/xml.
Evidently this client cannot be changed so am trying to find out if there is anyway to force my server to accept this content-type?
Tichodrama was right. The client was not a soap client. It was instead sending xml over HTTP POST.
I was dealing with the same issue and finally i had to add a servlet that accepts Content-Type defined as application/x-www-form-urlencoded and internally this servlet invokes all the SOAP logic behind.
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.