I am using SAAJ at the client side for sending a soap request. I am also attaching a random binary string as an attachment to the SOAP request, using this API.
soapMessage.addAttachment(attachment);
When I sniff this request through wireshark, I can see my attachment outside the <SoapEnv>,
but when this request reaches the client side (which is implemented using the JBoss libraries), I only get the message and not the attachment.
I have not specificed anything in the WSDL related to the attachments.
I can't figure out what can be the problem.
Any pointers would be helpful.
Do you send along the right Content-Type, Content-Transfer-Encoding and Content-ID header values?
http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html#Value-space_of_Content-Id_Header
Maybe post the generated soap-message
Related
Colleagues,
I have SOAP web-service based on CXF implementation with enabled SSL & WSS configuration (cofigured using WSP).
I have test tool for testing this service also written using CXF.
Positive cases are working. Trying to test negative cases with security errors (wrong certificate / signature).
I have requirement from customer that in case of security errors return fault:401 and HTTP response code 401.
Problem:
When I return HTTP code 401 from web-service on receiver side (in test tool) I receive Marshaling errors because of incoming internal InputStream is empty (without content). When I return any other HTTP code (200/403/419/500/503) - there isn't any problem on receiver side! And I'm able to see SOAP fault with message generated in web-service side.
Questions:
Maybe there are some specific handling 401 HTTP code in CXF ?
Maybe there are some specific requirements in SOAP in general ?
If returning 401 HTTP code in SOAP it's bad practice could you please provide documents/source code to prove this behavior and help me change customer requirements. I tried to look throw the code and haven't find place where this case handles
P.S: Tried to capture traffic using WireShark and RawCap and tried to decode it without success.
I think answer in this question will help you
question
The question also includes a reference to the soap specification for your customers about fault response codes.
Be careful because there are some major differences between SOAP 1.1 and SOAP 1.2 in the allowed HTTP status codes when a SOAP fault is returned.
in SOAP 1.1, the status code must always be 500 “Internal Server Error”.
in SOAP 1.2, it varies based on the type of the SOAP fault
I use Java SOAP web-service based on Axis2 1.4.1 to exchange data and attachments since years; no matter so far even if big attachments since the web-service implements MTOM.
This till last week, when a webservice WS client started sending huge attachments (around 1GB) as base64 inline text within the SOAP body (no MTOM no SwA).
I was confident that Axis2 attachment caching feature would solve also in this case, but this is not true and OutOfMemory occurs.
After some attempts my understanding is that attachments are cached to disk (and not kept in memory) only if the WS client sends them as MIME parts.If sent as base64 text within the SOAP body they are kept in memory.
I also tried to replace Axis2 with CXF (I'm prepared to change my WS framework if it is the only solution) but I experimented exactly the same behavior.
I'm wondering if I'm missing something or someone having my same issue found a solution.
I cant't believe that my webservice can manage big attachments only if the client implements MTOM.
Thanks in advance for any possible suggestion.
In many Java specification I found SOAP support/run different protocols like HTTP, HTTPS, FTP, SMTP etc.
I searched on google but not found any example or implementation.
So can anyone here help me to understand this using example?
I haven't done it, but my assumption is it's just about the payload format, which would be Soap format. Your Webservice client, will consume the payload from an ftp location and do the processing just like http.
i am working on java with Netbeans IDE and glassfish 3.1.2 i have created in rest services using jaxrs. when request from client is made ,i need to send json data in compressed format.to do this i have enabled the compression in glassfish as shown the following picture
but response got from the server is not compressed using gzip. it is receiving as normal json data. what should i do to overcome this issue
This is a solution for GF 3.1.2.2.
Responses to HTTP requests in version 1.0 are not compressed. You must send your requests in HTTP 1.1 to get gzipped responses from your glassfish server.
More over, you must add the header "Accept-Encoding: gzip" in your http requests.
To get a compressed response you need to have both sides agree to use it. You have configured GlassFish to send compressed responses. I can see that from the picture.
You need to make sure that your request to the services tells GlassFish that it can accept a compressed response. You normally do this by adding the following header to your HTTP requests: Accept-Encoding. You can read about the header in the RFC document that defines HTTP 1.1 request headers.
You can also get a lot of info from reading though SO questions about Accept-Encoding.
I have written a simple HTTP server using Java and want to send some additional information (puzzle parameters and a small puzzle solver program) to the client i.e. a regular browser.
Similarly, the browser is also supposed to send information (solution) back to the server.
Is there a way to do this by just transmitting this information over the HTTP headers?
Thanks a lot
the headers are usually used to add http protocol relevant information.
You should probably use either the body of the response or cookies to add the needed information.
Adding a cookie is done using the header so it kind of fits what you are asking for.
But I wonder why you need to put it in the header? it seems like what you are asking for is url parameters (client to server) and response body (server to client).