php SOAPClient and SOAPServer in non wsdl mode require an array of options.
the location in options used to point where is the web service server file
but what do the uri in options?? because i change it to every thing and the web server is work fine
$options = array(
'uri' => 'http://aahshhs.com', //wath do this line?????
'location' => 'http://localhost/exer/Server.php',);
An array of options. If working in WSDL mode, this parameter is optional. If working in non-WSDL mode, the location and uri options must be set, where:
location is the URL of the SOAP server to send the request to
uri is the target namespace of the SOAP service.
Source: https://www.php.net/manual/en/soapclient.construct.php
Related
I have an ember-cli project using ember2.3 that is proxying to a server api. Right now, for my development environment, for example, I use this to proxy to the node server at :3000.
ember serve --proxy http://localhost:3000/
Part of my server side code needs the subdomain of the url to fetch data. Before, in Ember1.7, because I was not using ember-cli and not proxying, the subdomainName could be gotten via req.subdomains. But now, i need to make sure that the subdomain is being sent in the request's headers via the RESTAdapter.
Therefore, I need a way to get the current url and subsequently the subdomain of the url that the application is at.
For example, if I were current at the path:
http://dev.localhost:4200/users
I would need to parse out "dev" and send it in the request headers. How would I get that subdomain and/or the url.
First get hostname and then subdomain
let hostname = window.location.hostname; // `dev.localhost` for you
let [subdomain] = hostname.split('.'); // `dev`
Here's our current setup: (assume everything is using https)
Web Services server running a simple asp.NET Web API 2 application that returns only JSON. (api.example.com/controller/blah)
Primary web server that's going to contain scripts that use AJAX to access resources through our Web Services.
My end goal is to not have to deal with CORS because IE is being problematic. (I've tried several jQuery plugins to resolve problems with XDomainRequest, on top of our domain security settings causing IE to deny the requests anyways... it's just a mess.)
Route requests from www.example.com/api/* to api.example.com/* and return the JSON response.
However, when I've attempted to set this up with IIS + URL Rewrite + Application Request Routing (ARR) I get the following message when attempting to load up my url:
502 - Web server received an invalid response while acting as a gateway or proxy server.
There is a problem with the page you are looking for, and it cannot be
displayed. When the Web server (while acting as a gateway or proxy)
contacted the upstream content server, it received an invalid response
from the content server.
My setup in IIS is the following:
In ARR, I just ticked the Enable proxy option.
In URL Rewrite, I set up a rule with:
Match PRL Pattern = api/* (Using wildcards)
Action type = Rewrite
Rewrite URL: = api.example.com/{R:1}
I've made sure I can access the web services and data is returned correctly from the context of my web server. I've made sure the actual URL Rewrite rule is being triggered and forwarding the request correctly... but after that, I'm stuck. Any ideas?
I am trying to call a SOAP RPC style web service and getting the following error:
Exception in thread "main" com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 302:
This is a https web service and I have imported the certificate into cacerts thru browser but getting same result. Please note that, I can consume a REST webservice from the same machine without importing the certificate.
What I am missing when calling a SOAP service? Is it my client issue or something need to be done on the server side. I have access to the server.
HTTP status code 302 is a redirect, and so is unlikely due to a certificate problem. My initial guess is that you need to add a / (or remove it) from your URL. Some http server frameworks will redirect when a resource does not end in a /, so, instead of:
GET /myRpcEndpoint
Try
GET /myRpcEndpoint/
The other possibility is that this resource requires authentication and the server is redirecting you to a login page. If you want to know what is going on (and not guess), take a look a the the response headers for the 302. There will be a Location header telling you where the server wants you to go instead.
Had a similar issue where client code would receive a HTTP 302 error code when communicating with https and would work fine when communicating with http. In client code,you might need to specify the endpoint address on the request context using the BindingProvider.ENDPOINT_ADDRESS_PROPERTY property. Following the JAX-WS paradigm, the example below should work.
Please note that only the BindingProvider.ENDPOINT_ADDRESS_PROPERTY needs to be defined, the rest of your code should remain the same.
public static void main(String args[]) throws {
ObjectFactory factory = new ObjectFactory();
GetProducts_Service service = new GetProducts_Service();
GetProducts getProducts = service.getGetProductsPort();
final BindingProvider getProductsBP = (BindingProvider) getProducts;
getProductsBP.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
"https://example.server.net/ExampleServicesWar/GetProducts");
GetProductsRequest request = factory.createGetProductsRequest();
GetProductsResponse response=getProducts.getProducts(request);
List<Product> products=response.getProducts();
}
All you have to is to use correct end point url
((BindingProvider)port).getRequestContext().put(BindingProvider.
ENDPOINT_ADDRESS_PROPERTY, "https://yourservice");
Need to import at the top:
import javax.xml.ws.BindingProvider;
port is Method call:
full source:
private static String getApplicationStatus(java.lang.String remoteAccessKey, java.lang.Integer responseId) {
net.quotit.oes._2010.ws.applicationstatusupdate.OASStatusUpdateService service = new net.quotit.oes._2010.ws.applicationstatusupdate.OASStatusUpdateService();
net.quotit.oes._2010.ws.applicationstatusupdate.IApplicationStatusUpdate port = service.getStatusUpdate();
((BindingProvider)port).getRequestContext().put(BindingProvider.
ENDPOINT_ADDRESS_PROPERTY, "https://servicename/basic");
return port.getApplicationStatus(remoteAccessKey, responseId);
}
I am badly stuck with a SOAP based integration using Axis2 framework for generation of client stubs from the Server WSDL. The scenario is as follows :
There is always a login API call first, which gives a Success response in SOAP body and Temporary Redirect in HTTP header. Also provides a URL which contains the session ID in the Location field of HTTP Header.
The next API call is required to be made at this redirect location. IN THE SAME TCP CONNECTION, for getting a proper response.
Now, the problem is, as a part of Webservice implementation using Axis2 generated stubs, I need to reload this redirect URL and re-instantiate it as --- "stub=new Stub(newurl)"
As soon as this is done, it creates a new TCP connection and so, the next request gives the response as "session ID invalid" because it goes out-of-sync with login API.
I have tried everything mentioned as a solution in this forum and nothing is working out.
For e.g --
MultiThreadedHttpConnectionManager httpConnectionManager = new MultiThreadedHttpConnectionManager();
HttpClient httpClient = new HttpClient(httpConnectionManager);
ServiceClient serviceClient = stub._getServiceClient();
Options opts = stub._getServiceClient().getOptions();
opts.setTo(new EndpointReference(prop.getProperty("target_end_point_url")));
opts.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, Constants.VALUE_TRUE);
opts.setProperty(HTTPConstants.CACHED_HTTP_CLIENT, httpClient);
serviceClient.setOptions(opts);
stub._setServiceClient(serviceClient);
Similarly, I have tried many other options too. But it's not helpful at all.
Faced exactly the same issue.
Following steps solved the issue.
1. Using HttpClient, perform login. Don't use stub object to perform login.
2. Use the Location Header URL, to create new stub object i.e. stub = new Stub(locationURL). (Your existing options setting should be retained.)
3. There is a default timeout, by which server disconnects the TCP connection. In my case it was 50 seconds. Hence as soon as i performed login in step 1, i execute a timer every 40 seconds, to send an empty requests to new Location URL using HeadMethod of same HttpClient object.
I am trying to understand what things happen in the background when using a website OR basically what are the things that happen when a user interacts with a browser. I understand that this is a huge list and highly dependent on architecture and user actions etc, I am just trying to get a feel of major things and flush my misunderstandings and also use this to read more about stuff I don't understand.
As an exercise I am trying to note down things that happen in the background with respect to users action in a browser. Here is my attempt at this bit open ended but fun question:
User enters a url => browser checks if
available in browser cache => DNS look
up [root dns lookup => recursive dns
=> get ip ] => establish a tcp connection => send http req => get
the static page from web server=> if
authentication is required that
happens [either read cookies from
browser OR ask user to enter
credentials] => somehow gets the
dynamic elements as well [how ? ,
there is some lazy initilization here
?] => Then user performs some
action[clicks a link or something] =>
check browser cache => if not avail
[take the input parameters and embed
in the url in some manner [may be
encrypt some things if required] =>
hits a load balancer => directed to a
application server [depending on how
the LB selects a host] => application
server cache is checked [memcached or
some kind of caching, not sure if this
"normally" happens here or at some
other level] => application server
tries to understand the request [if
its a service listening on some port,
http port 80 it will get the URL and
parse to perform some operations] =>
database is queried if required to =>
there might again be connection
mgmt/caching/parallel queries etc here
=> database returns back the result to app server => app server creats a
result payload and headers [http] =>
sends it to browser for rendering =>
browser cache is updated => user
reacts to the response.
I have not considered retries/failures and how they are handled, but I would like to get some input there as well in a general sense
Note:
I am looking at things in general, I am sure that few companies might do it in different way etc etc. I will like to hear alternatives as well though!.
This is an effort to try and get more
perspective and read on few things
that will help me in general.
Clearly I have made an honest attempt
I also hope this would help others
looking at the question in general to
learn something new.
I am not asking
for opinions etc, so this aint a
completely open ended question [not
everything is right though there are
many options]
Thanks !
There is no difference between static or dynamic for browser. Browser makes HTTP request and gets HTTP response. If response is an HTML page, then browser renders HTML ,applies styles, and executes JavaScript code that come with page. This page can by dynamic or static - browser don't care! The side is care - is server side. If page is static, than HTTP server will just take page from disk and send it to client as HTTP response. If page is dynamic, than HTTP server will call some application and will ask this application to give requested resource. This application can be an PHP module for Apache(http server), or ASP.net for IIS, or even your C++ code that will generate any content you want.
How exactly page or resource (HTTP response can be also xml, or image etc) will be constructed depends on used application (server side technology).
As example, if you are using PHP - HTTP server will detect that requested resource has extension .php, server will pass this PHP file to PHP module for processing, and result will be sent to HTTP client(browser) as response.
When user perform some action, this is again just usual HTTP request. HTTP method GET and POST (look for article about HTTP on Wikipedia) is used to pass some input from server to client. Page can contain some heavy JS, that will make page look more like desktop application (rich controls, dynamically reacting on user action without request to server, or communicate with server in background), but this is not necessary for web application to be web application (for web site to by dynamic). It can be good old static HTML with HTML forms, and some server side code.
Web application is abstract entity that may consist from many HTTP resources (different URLs for server to response). Web application also is client-side code that communicates with server-side code thru HTTP with help of HTTP client(browser) and HTTP server. Web application is not some stand alone part, that only comes to work when user perform some action.
Web-service may fits this description - as thing that usually don't care about pages, and comes only when some action required. Its special type of web application, that expose some API thru HTTP(usually). You can request some resource, and pass some parameter, and you will get response with some result. It's same web application but without pages. But web-service usually part of big web application with pages, or even other part of same web-application (depending on how you look at this). It can be same server-side technology, and same HTTP server. And it's not necessary to create web-service if you want to make some web-application (dynamic web site).
Server-side part of web application can also communicate with some database, but it's not necessary too.
There can be real database, or just some text files on disk. And browser, client side code and HTTP server also don't care about database or source where server side code takes data.
Cache, load balancer, etc - it's just additional elements that usually are transparent for all this general stuff.
Cookies is passed with every HTTP request to HTTP server, and if requested resource is not static page, that HTTP server will pass them further to server-side code/application(part). And its usually how authentication and authorization works - cookies has contain info about session, and there is some data associated with session contains on server side - it can be ID of user, so server-side code will recognize user on every request.