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!
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.
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.
The ShallowEtagHeaderFilter which is part of Spring processes the If-None-Match header on an Http request. As part of the Http 1.1 spec this returns an Http status of 304 - Not Modified if the contents of the If-None-Match header sent on the request is the same as the Etag header. This is helpful for caching as it means that if the Etag is the same on the client and server then the contents will be identical.
This is fine.
However my question is this - does Spring have support for the If-Match header (again part of HTTP 1.1) rather than If-None-Match because as far as the docs go it looks like the ShallowEtagHeaderFilter only processes the If-None-Match header. I need the If-Match header to prevent simultaneous requests from overwriting the previous one. IE I only want the request to be processed if the Etags are the same and hence they have the latest version of the entity.
It doesn't look like the ShallowEtagHeaderFilter supports If-Match:
curl "Accept: application/json" -H 'If-Match: "somevalue"' -i http://localhost:8080/rest-sec/api/resources/1
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
ETag: "03cb37ca667706c68c0aad4cb04c3a211"
Content-Type: application/json;charset=UTF-8
Content-Length: 56
Date: Fri, 11 Jan 2013 14:58:40 GMT
I opened a JIRA issue to track this:
https://jira.springsource.org/browse/SPR-10164
BASIC QUESTION:
Is there a way to set the mime-type (content-type) of elements inside a jar that are pulled into a ZK theme?
Extended background (already posted to ZK Forums with no response)
We are building a theme .jar for our application, and I have gotten everything to work pretty well using zkTheme.bat. The problem I'm having, however, is that we are using PIE.htc (http://www.css3pie.com) in order to provide CSS3 capabilities to IE 7 and IE 8 (specifically just rounded corners, gradients, and box-shadow). The only way to link this inside the theme is to point it to the relative resource inside the jar like so:
behavior:url(${c:encodeURL(c:cat3('~./',project,'/PIE.htc'))});
where c: is the namespace for core, and project is the root directory of the project. This points to the correct file resource, but the header is not being set correctly. Doing a wget on the file, we get the following:
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Last-Modified: Thu, 28 Apr 2011 12:36:54 GMT
Cache-Control: public, max-age=31536000
Expires: Fri, 27 Apr 2012 12:36:07 GMT
Content-Type: ;charset=UTF-8
Content-Language: en-US
Content-Length: 28284
Date: Thu, 28 Apr 2011 14:08:23 GMT
Connection: keep-alive
Length: 28284 (28K) []
As you can see, the content-type is blank. This is probably because most of the files inside the .jar that are being served up are image resources, not behavior files. Here is what we get if we wget just the file itself.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"28280-1299679133268"
Last-Modified: Wed, 09 Mar 2011 13:58:53 GMT
Content-Type: text/x-component
Content-Length: 28280
Date: Thu, 28 Apr 2011 14:10:34 GMT
Connection: keep-alive
Length: 28280 (28K) [text/x-component]
So underlying issue is that Internet Explorer doesn't see the content-type header of "text/x-component" and therefore doesn't utilize the code inside the .htc to parse the CSS correctly. My question is therefore: is there a way to make zk serve up this file from the .jar as the proper content-type? Looking around at configurations I don't see a way to do it. Also, I can't find the underlying code that powers the extraction from the theme.jar in order to alter the code to figure out this content-type. I realize I can just drop the PIE.htc somewhere on the webserver and point to it outside of the theme jar, but that makes this code much less portable and therefore eliminates a pretty good portion of our logic to use the theme jar at all.
Please note: we're serving this up on Tomcat, and I've already checked web.xml to make sure text/x-component is bound, which it is (which is obviously the case or else the second wget wouldn't have turned out what it did).
So I discovered the workaround that fit my needs as quickly and easily as possible.
Basically, I just replaced the behavior.htc file with a behavior.htc.dsp file, and added the following line to the top:
<%# page contentType="text/x-component;charset=UTF-8" %>
My initial fear was that IE would not parse this as the proper filetype because of the extension, but apparently all it cares about it the content-type in the header, so this worked.
You can provide a EL function like c:encodeURL to manually specify the content type yourself.
You may refer to this tutorial of Defining Functions .