I want to intercept/sniff incoming HTTP request and filter/modify their contents (before they reach the application).
"Fiddler" seems to have this functionality, but for the sake of integration and portability I would rather have some library in Java/C to do this. Like JPCAP, for example. It intercepts IP packets, but, as stated, I need to intercept the -higher level- HTTP requests.
Furthermore, how can SSL encrypted (HTTPS) requests be read/modified in the same way?
Thanks in advance.
Have you tried Servlet Filters?
They wrap the HTTP request and so can modify the request before it gets to the servlet, and can modify the response as well. They can (and are) used to wrap third-party servlets and JSPs.
Because they are in the servlet container, you have secure, unencrypted access to both the request and response.
Related
Is there any way to achieve multiple responses from a single request using Spring Boot ? If yes, please provide me a link.
HTTP does not work this way. An HTTP request has exactly one response. Spring Boot will not let you send more than one response, because that would be against the HTTP specification and no HTTP clients would be able to figure out what was going on.
There may be another way to accomplish your underlying goals, but whatever it is, it won't involve sending more than one HTTP response to a single HTTP request.
I am coming from servlet/web application world and started learning web services(SOAP based). I have gone through some of the webservice
tutorials. I am trying to draw the parallel between normal http request and webservice request. Here are my observations ;-
1)Both are HTTP request. Webservice is a also post request which contains soap envelope as request body. Soap envelope
is just a normal xml which contains the data
2)java Stub internally marshal the XML , creates HTTP request and send it to consumer
3)Servlet at consumer side intercpets that request and unrmashal it to java object and send it to corresponding service.
Is my observation correct ? I know there may be other complexities but i tried to put the comparison in simple manner.
Your assumptions are generally correct. Yet, the subtelties can lead to huge differences.
Claim 1 : both are HTTP.
SOAP is generally used with an HTTP "binding". Yet it does not have to be that way. SOAP is designed to be fairly transport agnostic. It is not uncommon to have SOAP being used over JMS (although one might consider this an overuse of JMS, and an over architected protocol), it is certainly in production in many places. Rarely seen are SOAP/SMTP or SOAP/TCP without HTTP, but these exist too.
Webservice is a also post request which contains soap envelope as request body
A SOAP call over HTTP is a POST request. It may not be of content-type xml, though, as some variants such as SwA (SOAP with attachments) or XOP+MTOM variants may produce HTTP payloads that are MIME/Multipart (the first part of which is the SOAP Enveloppe in its pure XML form).
This use cas is most common when on is to send large binary content over a SOAP Call, and for which binary encoding may add a large weight to the request (base64 is a 1.3x factor in weight).
java Stub internally marshal the XML, creates HTTP request and send it to consumer
That is the usual way it is done, Axis framework and JAXWS frameworks work primarily this way.
The older SAAJ API, a standard EE API, requires you to build your SOAP Message by hand, using the DOM APIs, (see SOAPMessageFactory), and then send it.
If you look at Spring WS, you'll have something close to your claim, but where each part is fairly exposed and in your control (you may elect to build certain calls with a DOM Api, others by using JAXB marshalling, ...).
3)Servlet at consumer side intercpets that request and unrmashal it to java object and send it to corresponding service
Again, this is how things generaly work. But you can also have an implementation that works outside a servlet container. (See Endpoint Service API in JAX WS).
Your assumptions are right:-
Yes, Servlet request and Web service request both are normal HTTP request and yes, SOAP web service internally use HTTP POST.
Yes,java internally marshal the XML. Also, at client end one java web service client(may be a wrapped in servlet) un-marshal it. A SOAP message or SOAP type web service has many characteristics like:-
SOAP message mostly send data using XML format. XMLs are technology independent. So, SOAP can interact with two heterogeneous web applications built in two separate technologies and exchange data using XML.
SOAP web services send XML using HTTP protocol. Data are sent wrapped in an XML using the payload of HTTP.
SOAP web services can be secured. For an example, all the payment related transactions using credit card and bank info are done using secured SOAP web services.
A SOAP web service accepts XML in request and returns XML in response. In case of errors this return XMLs can also contain SOAP faults. SOAP faults contain the description of error and an error code.
Web services can carry attachment document also like PDF, Word etc. with its XML payload. Java provides separate API for this type of web services. There is an API available in java called SAAJ to accomplish this.
I think that you can find a very good response in this blog post by Ben Klopfer.
Mainly the difference between XML/SOAP vs HTTP/REST is that the former is most response verbose while the latter is lighter.
But this is not the only aspect you have to take into account.
REST represents the state of the resource and is a little bit easier to use and to understand, and always remember that it comes afterwards compared to SOAP.
In addition SOAP it is not limited to using HTTP/HTTPS, but can be also used with other transports like SMTP, JMS, etc.
Resuming the post reminds you:
Use SOAP when:
All you need is simple operations, like read only methods
Implementing a one-way or one-object service for something like data exchange or transfer
You want finer control over the specific transport of data, or can’t always use HTTP
Rigid specifications need to be enforced on incoming requests, and you want to minimize additional documentation needed for use
You can rely on client ability to parse XML, or more preferably SOAP itself
You need built-in error handling when things go wrong with requests
Use REST when:
Operations are complex, like create/read/update/delete on objects
Implementing a multi-faceted service for a variety of different objects
You want to easily and quickly target a variety of consumer end user devices as clients
Requests are generally stateless, like call and response compared to a conversation
Your clients may have limited bandwidth or processing power
You can leave it up to the client to get their requests correct and to deal with problems
Similar to HttpFilter (javax.Servlet.Filter ) which when added in web.xml can intercept any incoming request to JVM / outgoing (as response) independent of framework ( Spring/CXF/Jersy etc ) , I am trying to find an API which could intercept any outgoing HTTP calls from JVM to add/modify headers independent of framework. Also routing the requests through a proxy sounds overwhelming.
Quite often the word Outgoing HTTP call is misinterpreted in the forums so let me explain with example.
Let us assume there are two JVMs, jvm1 and jvm2. and there are HTTP calls being made from JVM1 to JVM2. I would like to intercept the HTTP connection being made from JVM1 to modify the headers information before the call happens. I do not want the code to be tied to a specific framework so that I can as bundle the interceptor as a jar and share it with application team. Changes in web.xml is fine.
Any suggestions? Please HELP!
Both JVM may use java.net.Socket or java.net.ServerSocket in any way for communication and there is no way to intercept anything here.
You may intercept any HTTP traffic if you connect thru a (transparent) proxy. The proxy will intercept anything and you may modify any content.
We went with aspectj. Not the best solution, but the only option we got.
If I have some APIs using SOAP, how do I know if the methods requires a GET, POST or other?
Also, What are the consequence (not even sure it would work) if I use a GET for a SOAP web service requiring a POST? or vice-versa?
Thanks, I'm still trying to get a good understanding on how to consume web services. I got some working with simple API's, but really having problem using a web service that returns is used to download files. Thanks again.
HTTP GET requests generally do not have a content part which how the SOAP message is transmitted to the server. This is why POST is used.
Specifically from RFC 2616 Section 4.3. Emphasis mine.
A message-body MUST NOT be included in a request if the specification
of the request method (section 5.1.1) does not allow sending an
entity-body in requests. A server SHOULD read and forward a
message-body on any request; if the request method does not include
defined semantics for an entity-body, then the message-body SHOULD be
ignored when handling the request.
EDIT:
As of SOAP 1.2 it is possible to use HTTP GET method and get a SOAP response back. I recommend reading the SOAP 1.2 primer Section 4.1 for details about which HTTP methods are appropriate in what situations.
Servlets are one way of handling requests/responses from a web client i.e. a client makes a request, server finds the appropriate servlet which can handle the request and generate the response which is then forwarded to the client.
Could someone please tell me ways of handling requests/responses other than Servlets. I know CGI is another option, what else can be used?
CGI is a poor choice for implementing HTTP protocol on the server-side. You can write the server manually (by opening a ServetSocket, parsing HTTP reauest headers and responding according to the spec, however this approach is very tedious and error-prone.
If you want to handle web client requests, servlets are basically the only reasonable choice. Of course there are tons of wrapping technologies and frameworks (web, SOAP, REST, AJAX...)