What is special with API Gateway, it is not required to include Access-Control-Allow-Headers in the response header.
This is AWS API Gateway Response Header:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 152
Connection: keep-alive
Date: Tue, 11 Oct 2016 02:39:40 GMT
Access-Control-Allow-Origin: *
x-amzn-RequestId: f3838f6a-8f5b-11e6-b13a-XXXXXXX
X-Cache: Miss from cloudfront
Via: 1.1 XXXXXXXXXXX.cloudfront.net (CloudFront)
X-Amz-Cf-Id: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX==
This is My Own Rest Server Response Header:
HTTP/1.1 200
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type
Content-Type: application/json
Content-Length: 335
Date: Tue, 11 Oct 2016 02:34:31 GMT
The Problem with My Own Rest Server is that I need include Access-Control-Allow-Headers in the response otherwise I will encounter Request header field content-type is not allowed by Access-Control-Allow-Headers in preflight response.
With AWS API Gateway, I am not encounter that error even the Access-Control-Allow-Headers is not in response header.
According to the documentation here, Content-Type should be allowed by default.
"Apart from the headers set automatically by the user agent (e.g. Connection, User-Agent, etc.), the only headers which are allowed to be manually set are:
Accept
Accept-Language
Content-Language
Content-Type
The only allowed values for the Content-Type header are:
application/x-www-form-urlencoded
multipart/form-data
text/plain"
Hope that helps, Ritisha.
I am using a SOAP webservice that is supposed to work with Java, PHP and a lot of technologies. However, it is only working correctly with PHP.
I used the SOAPClient class in PHP to implement the client. When I printed the request and response headers, I got something like this:
REQUEST HEADERS:
POST /ws/something.php HTTP/1.1
Host: xxx.com
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.5.30
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://example.com/ws/something.php/someMethod"
Content-Length: 417
Authorization: Basic <username:password here>
RESPONSE HEADERS:
HTTP/1.1 200 OK
Date: Thu, 03 Mar 2016 18:03:48 GMT
Server: Apache
Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
Content-Length: 512049
Vary: Accept-Encoding,User-Agent
Content-Type: text/xml; charset=utf-8
Set-Cookie: BALANCEID=balancer.<someIP>; path=/; HTTPOnly; Secure
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Then, I used SAAJ in Java to write the exact same request like how PHP does it. I edited even the user-agent to make it exact, but I have no luck. The response is always the SOAP service's wsdl. For some reason, the web service does not execute anything if I use Java.
These are the request headers for Java:
Authorization Basic <username:password here>
SOAPAction http://example.com/ws/something.php/someMethod
POST /ws/something.php HTTP/1.1
Host xxx.com
Connection Keep-Alive
User-Agent PHP-SOAP/5.5.30
Content-Type text/xml; charset=utf-8
Content-Length 417
This is the response header:
Date Thu
Date 03 Mar 2016 18:24:35 GMT
Server Apache
Strict-Transport-Security max-age=63072000; includeSubdomains; preload
Accept-Ranges none
Vary Accept-Encoding
Vary User-Agent
Content-Type text/xml; charset=UTF-8
Set-Cookie BALANCEID=balancer.<some IP>; path=/; HTTPOnly; Secure
Keep-Alive timeout=2
Keep-Alive max=100
Connection Keep-Alive
Transfer-Encoding chunked
Content-Length 8444
SOAPAction ""
Note how the response header is completely different.
I have no idea why the web service won't execute the exact same request from Java. It just returns the wsdl. Does that mean something is wrong with my request or does the web service magically work only with PHP soapClient?
I try to create a session connecting an Android phone to a Java backend.
For this I call an url looking like this: https://sub.domain.com/path-web/rest/user/init
HTTP/1.1 302 Found
Location: https://path.domain.com;jsessionid=SOMEID.frontend2
Content-Type: text/plain; charset=UTF-8
Content-Length: 0
Connection: close
Set-Cookie: JSESSIONID=SOMEID.frontend2;
Path=/; Secure; HttpOnly
Date: Fri, 24 Oct 2014 08:32:17 GMT
This causes my http library, in this case okhttp to try to follow the redirection to https://path.domain.com;jsessionid=SOMEID.frontend2.
This now fails because parsing this url with java.net.URI produces an URI with a null host.
Also Chrome want open the url at it is.
Is the url created wrong from the backend or is the parsing of the url wrong in java.net.URI?
What can I do to work with urls like that?
As described in the comments. The url is not valid and therefore not parsed from java.net.URI.
If I run a webapp under the uri /myapp then as soon as the app is accessed via http://example.com/myapp, the URL changes to http://example.com/myapp/. Is there any way to prevent this?
When you have such a behaviour your web (or application) server returns a
301 Moved Permanently
when the URL without slash is requested.
You can see a similar example when getting http://www.google.es/services
HTTP/1.1 301 Moved Permanently
Location: http://www.google.es/services/
Content-Type: text/html; charset=UTF-8
X-Content-Type-Options: nosniff
Date: Wed, 11 May 2011 15:24:06 GMT
Expires: Fri, 10 Jun 2011 15:24:06 GMT
Cache-Control: public, max-age=2592000
Server: sffe
Content-Length: 227
X-XSS-Protection: 1; mode=block
After this first HTTP get to http://www.google.es/services
(without slash), the browser makes a second HTTP get to http://www.google.es/services/ (with slash). You can trace the HTTP requests with Network tab in Firebug, for example.
You can check your web/application server configuration, and maybe you can change this behaviour.
I have a Vanguard webservice which I can call (using basic authentication) using a custom java class. The java wsimport tool was used to generate the java proxy stubs and this all works perfectly.
The java code (All classes below are generated by wsimport given a url + authentication info):
Authenticator.setDefault(new SimpleAuth(username,pass));
MyWSObject obj = new MyWSObject(url); -> triggers the exception
ServicePortType port = obj.getServicePort();
OutputType result = port.MyWSMethod(params);
OutputData data = result.getOutputData();
When I run the exact same java function (containing the above code) from matlab the webservice call fails with an obscure error:
??? Java exception occurred:
com.sun.xml.internal.ws.streaming.XMLStreamReaderException: XML reader error: com.ctc.wstx.exc.WstxUnexpectedCharException:
Unexpected character '"' (code 34) in DOCTYPE declaration; expected a space between public and system identifiers
at [row,col,system-id]:
[1,63,"<my webservice url>"]
at com.sun.xml.internal.ws.streaming.XMLStreamReaderUtil.wrapException(XMLStreamReaderUtil.java:256)
at com.sun.xml.internal.ws.streaming.XMLStreamReaderUtil.next(XMLStreamReaderUtil.java:84)
at com.sun.xml.internal.ws.streaming.XMLStreamReaderUtil.nextContent(XMLStreamReaderUtil.java:99)
at com.sun.xml.internal.ws.streaming.XMLStreamReaderUtil.nextElementContent(XMLStreamReaderUtil.java:89)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.hasWSDLDefinitions(RuntimeWSDLParser.java:209)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:119)
at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:254)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:217)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:165)
at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:93)
at javax.xml.ws.Service.<init>(Service.java:56)
at edu.soton.decode.activities.vanguardws.MyWSObject.<init>(MyWSObject.java:42)
at edu.soton.decode.activities.VanguardActivity.execute(VanguardActivity.java:80)
If I use wireshark to monitor the requests/reponses in both cases I see:
== Java function called directly ==
All the calls/reponses below happen automatically by the JAX-WS code generated by wsimport. My code just calls the webservice method on the generated service proxy, nothing fancy.
GET /bin/ws.dsb?wsdl/mywebservice HTTP/1.1
User-Agent: Java/1.6.0_22
Host: myhost
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
...
HTTP/1.1 401 Authorization Required
Server: Vanguard Server/5.1.10
Connection: close
Content-Length: 608
Date: Mon, 01 Nov 2010 15:04:17 GMT
Last-Modified: Mon, 01 Nov 2010 15:04:17 GMT
Expires: Mon, 01 Nov 2010 15:04:17 GMT
Cache-Control: no-cache
WWW-Authenticate: Basic realm="Local Library"
Auto-Studio-Login: 0
Content-Type: text/html
...
GET /bin/ws.dsb?wsdl/mywebservice HTTP/1.1
User-Agent: Java/1.6.0_22
Host: myhost
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Authorization: Basic Z29yaXNzZW46ZGlyaw==
...
HTTP/1.1 200 OK
Server: Vanguard Server/5.1.10
Connection: close
Content-Length: 5408
Date: Mon, 01 Nov 2010 15:04:17 GMT
Last-Modified: Mon, 01 Nov 2010 15:04:17 GMT
Expires: Mon, 01 Nov 2010 15:04:17 GMT
Cache-Control: no-cache
Set-Cookie: KillIDws=lpvovmb3oa9; path=/
Content-Type:text/xml
...
POST /bin/ws.dsb?soap/mywebservice HTTP/1.1
Content-type: text/xml;charset="utf-8"
Soapaction: ""
Accept: text/xml, multipart/related, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
User-Agent: JAX-WS RI 2.1.6 in JDK 6
Host: myhost
Connection: keep-alive
Authorization: Basic Z29yaXNzZW46ZGlyaw==
Content-Length: 214
...
HTTP/1.1 200 OK
Server: Vanguard Server/5.1.10
Connection: close
Content-Length: 851
Date: Mon, 01 Nov 2010 15:04:18 GMT
Last-Modified: Mon, 01 Nov 2010 15:04:18 GMT
Expires: Mon, 01 Nov 2010 15:04:18 GMT
Cache-Control: no-cache
Set-Cookie: KillIDws=lpvovmb3oi2; path=/
Content-Type:text/xml; charset=utf-8
...
-> the last response is where the results are returned
== Exactly the same Java function called from inside Matlab ==
GET /bin/ws.dsb?wsdl/mywebservice HTTP/1.1
Accept: */*
Accept-Encoding: gzip
Accept-Language: en
User-Agent: Mozilla/5.0 (Java 1.6.0_22; Windows XP 5.2 amd64; en_GB) ICEbrowser/v6_0_2
Host: myhost
Connection: Keep-Alive
...
HTTP/1.1 401 Authorization Required
Server: Vanguard Server/5.1.10
Connection: close
Content-Length: 608
Date: Mon, 01 Nov 2010 15:02:42 GMT
Last-Modified: Mon, 01 Nov 2010 15:02:42 GMT
Expires: Mon, 01 Nov 2010 15:02:42 GMT
Cache-Control: no-cache
WWW-Authenticate: Basic realm="Local Library"
Auto-Studio-Login: 0
Content-Type: text/html
...
-> everything stops here with the exception shown above. So when running inside Matlab, it seems Matlab is doing something to the JVM environment that stops the generated proxy from making a second, authenticated call. It simply bails out after the 401 instead of authenticating like in the pure java case.
I have set MATLAB_JAVA environment variable so that the same JVM (sun 1.6) is used in both cases. I have also noticed that Matlab does not respect the http.agent property when sending requests.
It turns out that the problem only seems to occur on 64bit versions of Matlab on non-linux platforms. It works fine if I install a 32bit version of Matlab. I am going to mark this question as answered since this seems to be a problem with Matlab and Mathworks are investigating the issue (thread id: 1-DUMQQZ]).
If proxy settings are responsible for the issue, the following static methods can be used for configuration.
% configure
java.lang.System.getProperties().put('http.proxyHost', 'your.proxy');
java.lang.System.getProperties().put('http.proxyPort', 'port number');
java.lang.System.getProperties().put('http.proxyUser', 'name');
java.lang.System.getProperties().put('http.proxyPassword', 'password');
java.lang.System.getProperties().put('http.proxySet', 'true');
% verify
java.lang.System.getProperty('http.proxyHost')
java.lang.System.getProperty('http.proxyPort')
java.lang.System.getProperty('http.proxyUser')
java.lang.System.getProperty('http.proxyPassword')
% test
urlread('http://www.yahoo.com/')
ICEbrowser, which MATLAB still uses on some platforms for HTML rendering, inserts some of its own classes into global VM settings. This may work for you if you never open the Help Browser in the current session.