I am consuming a web service. I wrote a client with axis 1.4 using eclipse. I have access to webservices over ssl vpn. My axis client code works fine. However, code must be run on android device. I can not use axis code on android, because java rmi is not supported on android. I am trying to consume service with making httppost with apache httpclient library. In order to see axis request values, I used tcpmon. It helped me to write httppost code easily. The problem is that when I run code directly without using tcpmon it gives me the error below:
Exception in thread "main" java.net.SocketException: Invalid argument: setsockopt
at java.net.DualStackPlainSocketImpl.setIntOption(Native Method)
at java.net.DualStackPlainSocketImpl.socketSetOption(Unknown Source)
at java.net.AbstractPlainSocketImpl.setOption(Unknown Source)
at java.net.PlainSocketImpl.setOption(Unknown Source)
at java.net.Socket.setTcpNoDelay(Unknown Source)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.prepareSocket(DefaultClientConnectionOperator.java:254)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:185)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:643)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
at TTIncidentClient.main(TTIncidentClient.java:56)
If I send request over tcpmon it works. I get the response. I give you tcpmon output below:
REQUEST:
POST http://localhost:3333/SM/7/ws HTTP/1.1
SOAPAction: RetrieveList
Accept: application/soap+xml, application/dime, multipart/related, text/*
Pragma: no-cache
Cache-Control: no-cache
Authorization: Basic bW9iaXNlbTpPeXAlPzIwMTM=
Content-Length: 456
Content-Type: text/xml; charset=ISO-8859-1
Host: 10.6.105.132:3333
Proxy-Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.2.5 (java 1.5)
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><RetrieveIncidentListRequest xmlns="http://schemas.hp.com/SM/7"><keys query="flag=true and category="incident" and assignee.name="xx.yy""/></RetrieveIncidentListRequest></soapenv:Body></soapenv:Envelope>
RESPONSE:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=AF8B0B75ED768852E44D7CB49DB5DD88; Path=/SM
Keep-Alive: timeout=1200000, max=1000
Connection: Keep-Alive
Content-Type: text/xml;charset=utf-8
Content-Length: 2009
Date: Sun, 11 Aug 2013 22:12:17 GMT
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><RetrieveIncidentListResponse message="Success" returnCode="0" schemaRevisionDate="2012-11-12" schemaRevisionLevel="0" status="SUCCESS" xmlns="http://schemas.hp.com/SM/7" xmlns:cmn="http://schemas.hp.com/SM/7/Common" xmlns:xmime="http://www.w3.org/2005/05/xmlmime" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.hp.com/SM/7 http://testsc:3333/SM/7/Incident.xsd">......</SOAP-ENV:Body></SOAP-ENV:Envelope>
Normally I expect tcpmon behaviour must be same with my local but tcpmon changes the result. What can be the reason ?
Very interestingly, instead of using apache httpclient or java urlconnection libraries , I wrote socket programming code for soap as in this example it worked. :)
Related
We have a legacy SOAP web service, implemented using Apache Axis 1. At the client environment, the response data sometimes gets truncated on certain API calls causing error. But when tested using SOAP UI client, it returns full data as expected. This behavior can't be locally replicated in our dev environment and happens only at client office. They do have front end proxies and stuff in place to route the request.
We are still using HTTP 1.0. Will that be causing any issues with a big payload? How much effort will it take to upgrade to HTTP 1.1? Will it be a simple header upgrade stating HTTP/1.1?
We are already encoding the data using utf-8 on request and response.
Sample SOAP request:
[POST /apixyzCall HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.1beta
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: "http://abc/SoapManager"
Content-Length: 983
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
PAYLOAD
</soapenv:Body>
</soapenv:Envelope>
]
Any tips?
Turned out the issue was with SSL. The API returns complete data using HTTP, but it truncates response once SSL is enabled. It was closing the connection before the client receives the full response.
I've a problem with broken connections and I believe this is due to an incorrect behavior respect to http keepalive but I can't understand if the 'culpit' is on the client or on the server side.
I'm dealing with a scenario where the client sends and HTTP 1.1 request with:
Connection: close
and the server does NOT reply with a Connection header.
The behavior is as follows:
The client sends the request
The server sends it response
The server does NOT close the connection
The client does NOT close the connection (.1)
The client sends another request using the same connection
The server does not do anything and after 30" closes the connection
The components are as follows:
Client: Java HttpConnection (within Dell Boomi iPaaS)
Server: SAP ERP OData Webservice
According to this article: "Should a server adhere to the HTTP Connection: close header sent from a client?" the problem seems to be on the client side. However the Java HttpURLCoonnection implementation should be pretty robust (tested x64 server VM on Linux v 1.7.0_55-b13 and x64 server on Windows 7 v 1.7.0_75-b13).
Here are the complete set of headers from the 1st request from client:
GET /sap/opu/odata/SAP/ZZSALESORDER_SRV/$metadata HTTP/1.1
User-Agent: Boomi Http Transport
Authorization: Basic YmPRIVATESECRETPLEASExNg==
X-CSRF-Token: Fetch
Connection: close
Cache-Control: no-cache
Pragma: no-cache
Host: some.server.behind.firewall.local:8000
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Cookie: sap-usercontext=sap-client=100; SAP_SESSIONID_DEV_100=Cm7LsDSECRETSECRETSECTERFaIMak%3d
And these are the ones from the response from the server:
HTTP/1.1 200 OK
content-type: application/xml
content-length: 79750
x-csrf-token: oolTHISAGAINISASECRET3PA==
last-modified: Fri, 25 Mar 2016 17:55:35 GMT
dataserviceversion: 2.0
After the server has replied the client sends a second request using the same connection:
PUT /sap/opu/odata/SAP/ZZSALESORDER_SRV/SalesOrderItems(NumDocSap='1200001534',PosId='000020') HTTP/1.1
User-Agent: Boomi Http Transport
Content-Type: application/atom+xml
X-CSRF-Token: oolZMYSECRETPA==
Connection: close
Authorization: Basic YmPRIVATESECRETPLEASExNg==
Cache-Control: no-cache
Pragma: no-cache
Host: some.server.behind.firewall.local:8000
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Content-Length: 406
Cookie: sap-usercontext=sap-client=100; SAP_SESSIONID_DEV_100=Cm7PRETTYPRIVATESECRETak%3d
and the server does not reply and closed the connection abruptly after 30".
The problem can be completely resolved setting the JVM flag
http.keepAlive=false
on the java client side (Boomi) but this seems more of a workaround then a solution.
Can someone please explain:
is there an HTTP protocol violation on client or server side?
can this be fixed by sending different headers?
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 have an implementation of Java's HttpServer that I use for testing its pretty basic and means I can adjust what is served up to the client on the fly. My code is using apache http client.
I would like to test some authentication using this Implementation but i'm having some issues. My problem is that my code never authenticates, the initial request is sent and the server responds with 401 but the http client never responds. It goes through the list of authentication types but never chooses BASIC
If i connect to the same url using my browser I am prompted and when i submit credentials it logs in. If i change my code so the code attempts to log into some other server it is successful, so i know that both ends work!
I have wiresharked the connection on the client and server side and the differences I can see are:
when the connection is successful the subsequent request is sent as a POST not a GET.
when my server responds the authentication header is Www not WWW (as it is when it works)
EDIT:
Looking through the http code the case sensitivity shouldnt be causing any problems. The first response is the one that fails and the second is the one that works:
Fails
GET /testing HTTP/1.1
Host: 192.168.30.65:8000
Connection: Keep-Alive
User-Agent: Apache-HttpAsyncClient/4.0-beta1 (java 1.5)
HTTP/1.1 401 Unauthorized
Content-length: 0
Www-authenticate: Basic realm="myRealm"
Works
GET /svn HTTP/1.1
Host: svnserver
Connection: Keep-Alive
User-Agent: Apache-HttpAsyncClient/4.0-beta1 (java 1.5)
HTTP/1.1 401 Authorization Required
Date: Mon, 16 Apr 2012 09:51:58 GMT
Server: Apache/2.2.3 (CentOS)
WWW-Authenticate: Basic realm="Subversion Repository"
Content-Length: 475
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Authorization Required</title>
</head><body>
<h1>Authorization Required</h1>
<p>This server could not verify that you
are authorized to access the document
requested. Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
<hr>
<address>Apache/2.2.3 (CentOS) Server at svnserver Port 80</address>
</body></html>
GET /svn HTTP/1.1
Host: svnserver
Connection: Keep-Alive
User-Agent: Apache-HttpAsyncClient/4.0-beta1 (java 1.5)
Authorization: Basic YQVkd2Gm3GS6dXNjbMk5
I make very simple HTTP server in Java. The response sent to the browser is
HTTP 1.1 200 OK
Server: OneFile 1.0
Content-Type: text/html; charset=utf-8
Content-Length: 202
Transfer-Encoding: chunked
<HTML><HEAD><TITLE>My website</TITLE></HEAD>
<BODY><H1>Document </H1>
</BODY></HTML>
mozilla firefox displays it as text/plain although it should be text/html Why?
I suspect the Setup info is ignored...is it any difference for browser if I make connection on port 8080?
Thanks for any help
The browser will honor your headers. Unfortunately, your response is malformed for several reasons:
the response should start HTTP/1.1, not HTTP 1.1
you specify Transfer-Encoding: chunked, but your response does not follow the chunked format.
It appears that Firefox, quite sensibly, refuses to interpret such malformed response and just shows it unchanged.