I use jersey 1.7. My client communicates with server over HTTPS. I figured out that HTTPS connection is established for each different request (URL). I would like to keep the same connection for multiple requests during specific period of time. I configure the client as it is describe in https://blogs.oracle.com/enterprisetechtips/entry/consuming_restful_web_services_with and send request via WebResource.Builder
public Response post(String actionName, Request request) {
WebResource webResource = rwsClient.resource( serverURL + actionName);
WebResource.Builder requestBuilder = webResource.accept(MediaType.APPLICATION_XML_TYPE);
Response response = requestBuilder.post(Request.class, request);
return response;
}
Connections from HTTP 1.1 requests are considered persistent unless declared otherwise.
If your client is making HTTP 1.0 request, they can pass the header "Connection: Keep-Alive"
Then you have to look at the connection timeout settings of your web servers. For Apache 2.2 for example, it is very low at only 5 seconds by default. Check your web server documentation.
Related
I have a WebSocket server written which only handles upgrade requests which are GET requests. If a POST or any other kind of request with the required headers comes it is handled by a HTTP server.
In the specification it is not stated explicitly that the WebSocket upgrade request should be a GET request.
If the upgrade request is not a GET request should the server handle it as a WebSocket upgrade request, should it pass it to be handled by the HTTP server or should it respond to it with a status code like 400 Bad Request ?
Could this be a design decision where the server decides not to handle methods which are not GET requests?
From section 4.1 (Client Requirements) of the webSocket specification, it says this:
The method of the request MUST be GET, and the HTTP version MUST
be at least 1.1
And, then later in section 4.2.1 (Reading the Client's Opening Handshake) of the webSocket specification, it says this:
The client's opening handshake consists of the following parts. If
the server, while reading the handshake, finds that the client did
not send a handshake that matches the description below (note that as
per [RFC2616], the order of the header fields is not important),
including but not limited to any violations of the ABNF grammar
specified for the components of the handshake, the server MUST stop
processing the client's handshake and return an HTTP response with an
appropriate error code (such as 400 Bad Request).
An HTTP/1.1 or higher GET request, including a "Request-URI"
[RFC2616] that should be interpreted as a /resource name/
defined in Section 3 (or an absolute HTTP/HTTPS URI containing
the /resource name/).
So, there are multiple places where it says the http request must be a GET.
As for your specific questions:
Should WebSocket server only handle GET requests?
Yes, a webSocket connection will always start with a GET request, not a POST or any other method.
If the upgrade request is not a GET request should the server handle it as a WebSocket upgrade request, should it pass it to be handled by the HTTP server or should it respond to it with a status code like 400 Bad Request ?
As described in the above reference portion of the specfication, the server should respond with a status code like 400 Bad Request.
Could this be a design decision where the server decides not to handle methods which are not GET requests?
Yes.
I am new to Java SOAP web services. Recently I have created a web service using the JAX-WS specification. This is deployed in the WebLogic server I am using in my machine. Now when I want to invoke the web service from the web application written in JavaScript remote machine on another server, it giving me the following error.
I have also browsed for some other similar kind of posts like this
I am sending the request using JavaScript and SoapClient.js Library.
My invocation code is:
SOAPClient.invoke("http://inhydkvaranasi1:7001/TodoWS/TodoListService",
"getTodos", p1, true, function(data) {
$("#todolist").html('');
if (Object.keys(data).length < 1) {
$("#todolist").html(
"<h4>No Todos Available right now!</h4>");
} else {
Object.keys(data).forEach(
function(key) {
$("#todolist").append(
"<li>" + data[key]["task1"]
+ "(Priority "
+ data[key]["id0"]
+ ") </p>");
});
}
});
The request sent by the XMLHttpRequest() object did not get a response header as Access-Control-Allow-Origin in the XML response.
How could I solve this problem? So that my web service can be used publicly by any user from different domain on different server.
Look at the CORS HTTP headers (from codingpedia.org):
Client side HTTP request headers. These are headers that clients may use when issuing HTTP requests in order to make use of the cross-sharing feature:
Origin: URI indicating the server from which the request initiated. It does not include any path information, but only the
server name
Access-Control-Request-Headers: used when issuing a preflight request to let the server know what HTTP headers will be used when the
actual request is made
Access-Control-Request-Method: used when issuing a preflight request to let the server know what HTTP method will be used when the
actual request is made
Server side HTTP response headers. These are the HTTP headers that the server sends back for access control requests:
Access-Control-Allow-Origin: specifies the authorized domains to make cross-domain request (you should include the domains of your
clients or “*” if you want the resource public and available to
everyone – the latter is not an option if credentials are allowed
during CORS requests)
Access-Control-Expose-Headers: lets a server white list headers that browsers are allowed to access
Access-Control-Max-Age: indicates how long the results of a preflight request can be cached.
Access-Control-Allow-Credentials: indicates if the server allows credentials during CORS requests
Access-Control-Allow-Methods:
indicates the methods allowed when accessing the resource
Access-Control-Allow-Headers: used in response to a preflight request to indicate which HTTP headers can be used when making the
actual request
I am sending requests to Elasticsearch over HTTP from a Java client using Jest. Since my requests must traverse the public Internet, I am using an Nginx proxy in front of Elasticsearch to provide SSL and HTTP Basic Auth. However, I don't see a way to set HTTP Basic Auth credentials with Jest.
Is it possible to use HTTP Basic Auth with Jest? If so how?
HTTP basic auth can be sent as a header.
String authHeader = "Basic " + new String(Base64.encodeBase64(String.format("%s:%s", username, password).getBytes()));
Index index = new Index.Builder(json)
.index(indexName)
.type(type)
.id(id)
.setHeader("Authorization", authHeader)
.build();
JestResult result = client.execute(index);
I'm picking my way through the dartiverse_search example from the welcome page in dart editor. I see that it uses a path route to decide whether to transform a request into a websocket:
// The client will connect using a WebSocket. Upgrade requests to '/ws' and
// forward them to 'handleWebSocket'.
router.serve('/ws')
.transform(new WebSocketTransformer())
.listen(handleWebSocket);
Is it possible to turn a request into a websocket without using a routing path, for example using a query string to the root url?
You can specify any condition for upgrading to a WebSocket connection. You can even upgrade any connection request to a WebSocket connection without specifying a condition like this:
WebSocketTransformer.upgrade(request).then((WebSocket websocket) {
websocket.listen((String text) {
// process sent data
});
websocket.add(JSON.encode("Hello"));
});
If the request is not a valid web socket upgrade request a HTTP response with status code 500 will be returned. Otherwise the returned future will complete with the [WebSocket] when the upgrade process is complete.
I speack spanihs. Will try english.
I have a WSO2 proxy service for a backend SOAP WebService. It works fine!
The problem starts when i enable Response Caching for the proxy service, 20 seconds caching.
I set ports in TCPMonitor(localhost 8280 and the one for backend service).
I see that when i send different requests to the proxy, it returns same cached response. It return the response cached for the first request into that 20 seconds of life into the cache.
Differents body http for different requests, but same headers and POST URI.
Does ESB do the hash with headers+body or only the headers?
Thansk for your help
Diego
Are you suing cache mediator?
cache mediator caches the response, whenevr it sees same request comes to the system, it sends back the cached response.
Or else did you enable the response caching fro proxy services?