I am using a Grizzly HttpServer and i want to add a specific header in every response. Specifically, i want to avoid CORS problems by adding an 'Access-Control-Allow-Origin' header.
So, ideally, i want something like this:
HttpServer server = GrizzlyServerFactory.createHttpServer(uri, crc);
server.setHeader("Access-Control-Allow-Origin" , "*");
Generally, i am looking for a solution that does not require that i have to manually insert this header in every request-response action.
Is there any way to do this?
As #alexey said, there is no way (from the current Grizzly Server version) to do this. If anyone finds something else that works, i will gladly confirm it as an accepted answer.
The best alternative that works quite well is to extend the 'ContainerResponseFilter' class and override the 'filter' method.
Here is an example for 1.x API
Here is an example for 2.x API (minor changes)
Related
Lets say I have rest endpoint for my Driver resource.
I have PUT method like this
myapi/drivers/{id}
{body of put method}
I need to add functionality which will allow to 'enable' and 'disable' driver
Is it good idea to create new endpoint for that like this?
PUT myapi/drivers/{id}/enable/false
or it is better to use existing endpoint ? One problem with using existing endpoint is that driver has lot's of fields(almost 30) and sending all those fields just for updating only 'enabled' or 'disable' driver is something overkill.
What do you think?
This is exactly what the HTTP method PATCH is made for. It is used in cases where the resource has many fields but you only want to update a few.
Just like with PUT, you send a request to myapi/drivers/{id}. However, unlike with PUT, you only send the fields you want to change in the request body.
Creating endpoints like myapi/drivers/{id}/enable is not very RESTful, as "enable" can't really be called a resource on its own.
For an example implementation of a Spring PATCH endpoint, please see this link.
Use PATCH Http metod to update one field
PATCH myapi/drivers/{id}/enable
How do I change HTTP method in javax,servlet.RequestDispatcher?
I have some old service APIs that support GET and POST, The new version supports DELETE method for removing a record which used to happen through POST earlier.
We are decommissioning old version APIs by setting RequestDispatcher.forward() for old end points (stop gap arrangement until clients change). everything was cool except this POST to DELETE mapping.
Any solution there for this problem without adding POST end point for delete operation in new API?>
Although I agree using the next layer after your servlets would be a better choice, this is interesting. It use to be common to wrap an incoming request to add request based functionality (IE: auth state, etc). The HttpServletRequestWrapper was used to accomplish this. You could do the following if you just need to change the method:
class PostDeleteAdapter extends HttpServletRequestWrapper {
public String getMethod(){ return "POST"; }
}
You may also change other aspects of the incoming request if you need to further adapt the request. This may play well with your servlet containers RequestDispatcher, however it's dependent upon the container entirely.
I think you can't do it using servlet API. You can do what you want creating a new request, processing it's response and sending it back through the original response (in the servlet).
Some http clientes might help you. See Apache HTTP client:
http://hc.apache.org/httpclient-3.x/methods/delete.html)
I am using Apache Camel CXF to integrate a SOAP WebService. Everything works fine but I have noticed that my response is coming back as HTTP 202 instead of 200. I am kinda concerned because I know many people hardcode things like if(httpCode == 200) {...} and this could break the current service.
I have tried using different interceptors to override the HTTP code from 202 to 200, but no luck. Also, 202 means Accepted which means the request is in process but not finished. 200 means OK which means the process has finished. Does this means that I am doing something wrong in my route?
What is the right way of fixing this? Interceptor? Setting a Camel headers? Doing something in the route to say it's complete?
I am using Apache Camel 2.12.1 and PAYLOAD mode.
EDIT: It seems something related to OneWay endpoint. Is there any way to deactivate that?
EDIT2: After hours trying things I think I have the root cause. My WSDL is not defining any output for that particular operation. I cannot change the WSDL. That said, I believe that when CXF is using the WSDL for creating the endpoint it automatically assumes it is a OneWay endpoint since there is no output. That means the response is sent back as soon as we get the request with code 202. Also, I believe there is no possible OutInteceptor chain because of this reason. Personally I believe it's ok to send back 202 but it is a service requirement to send back 200. Is there any configuration I change in CXF to set that in OneWay endpoint mode?
Finally, we found an interceptor for doing that:
public class SoapResponseInterceptor extends AbstractSoapInterceptor {
public SoapResponseInterceptor() {
super(Phase.PRE_LOGICAL);
}
#Override
public void handleMessage(SoapMessage message) throws Fault {
message.getExchange().setOneWay(false);
}
}
Hope it helps!
I am using dropwizard for writing a webapp and also using Jersey Client as mentioned at
http://dropwizard.codahale.com/manual/client/#man-client-jersey
But it seems that whenever i try to do a post using the jersey client the remote webservice complains that Content-Length header is missing and fails.
public JobResponse createJob(JobRequest job) {
return jerseyClient.resource(URI.create(JOBS_URL))
.type(MediaType.APPLICATION_JSON_TYPE)
.header("Api-Key", job.getApiKey())
.post(JobResponse.class, job);
}
I have confirmed that the request does not contain the header and despite my best efforts I haven't been able to figure out why this is happening. Does anyone know if there is something that I am missing?
PS: The service that i am trying to hit is https://app.zencoder.com/docs/api/jobs/create
This is known "issue" and actually intended behavior.
Problem here is that entity is processed AFTER headers are written out to "the wire", thus Content-Length header value is not know when headers are serialized. If you need to have it, you have several options (with various complexity):
serialize entity by yourself; if you provide entity as string (or byte[]), Content-Length should be set.
create your own MessageBodyWriter, which would compute size of entity in getSize() method call.
there might be some other way how to do it, but I can't think of another right now.. hope it helps.
I was facing the same problem and the answer from Pavel didn't work out for me (I was using a FormMutiPart object).
I was using ApacheHttpClient4 instead of the regular com.sun.jersey.api.client.Client. Changing back to the Jersey Client, the Content-Lenght is calculated (at least in the case of FormMultiPart entity).
I am currently working on building a simple HTTP proxy using Apache Mina, in particular org.apache.mina.proxy, and I have a few questions about how to use some of the components.
How do I extract the future address from an incoming HTTP request? I
can see how to create a ProxyConnection given a URL, but I can't see how
to extract this from an incoming request. I have a feeling this leads
to my next question:
What is AbstractHttpLogicHandler for? I see it has a subclass, HttpSmartProxyHandler, but I am not sure if and how to use it.
Is there an example somewhere that I could look at? I've been looking at http://mina.apache.org/report/trunk/xref/org/apache/mina/example/proxy/ but it doesn't seem to answer my questions above.
I think that classes in org.apache.mina.proxy are classes to add proxy in you HTTP request and not classes you can directly used to build your proxy.
About your second point: AbstractHttpLogicHandler is an abstract class that decorates AbstractProxyLogicHandler
"AbstractHttpLogicHandler provides HTTP request encoding/response
decoding functionality"
HttpSmartProxyHandler is a concrete class that extends AbstractProxyLogicHandler.
This class fulfills its contract by handling a HTTP response from the proxy server (by implementing handleResponse(final HttpProxyResponse response))