I am using org.apache.http.entity.mime.MultipartEntityBuilder for sending the multipart form data using apache HttpClient in a SpringBoot Application.
Recently, I saw a usecase , where one of the request was giving response as
415 Unsupported Media Type
While trying to debug the issue, I changed the MultipartEntityBuilder object's HttpMultipartMode from BrowserCompatible to Strict . And it started giving the expected response 200.
I tried to search a lot but still not able to completely understand what impact does changing the HttpMultipartMode makes.
Can someone please help me to understand this?
You can check the source code for more information:
https://www.javadoc.io/doc/org.apache.httpcomponents/httpmime/4.5.7/org/apache/http/entity/mime/HttpMultipartMode.html
Strict seems to follow the RFC standards, BrowerCompatible not
When I have issues like these I usually make sure to test my request outside of Spring (i.e. Postman or similar) to understand the differences headers make (usually different headers will be the problem in some way)
Curious to know other side code, While implementing API (rest service), what changes make this difference. To make API strict mode what particular changes I have to make in code.
Related
I am trying to implement deprecation header for api responses in my application. The problem is that recently our codebase has gone through major refactoring and restructuring with lots of apis being deprecated. all of these api endpoints are annotated with #Deprecated. is there anyway i can use this annotation to change the response without having to make code changes at each and every endpoint location?
I have tried to change response in the code at each location and this would be tedious, expecting a smarter way to go about this.
Note- My application is in JAVA and uses spring-boot framework.
I have an API built in Java/Spring hosted on the cloud and recently came across CORS issues when a website couldn't use it. I found out my API wasn't supporting CORS. This is how I solved my problem:
https://spring.io/guides/gs/rest-service-cors/ (search "Enabling CORS" on the page)
By simply adding the #CrossOrigin annotation it will:
include CORS access control headers in its response
This seemed to solve my issue initially. However, due to the lack of involvement on my part to solve this issue (I just had to add the annotation) I'm obviously having some confusions. More issues cropping up. I noticed when inspecting my response that I have null values for getAllResponseHeaders and getResponseHeader. So my CORS response is not sending any headers back.
Questions:
In what scenarios do I need to send response headers back? After reading the Spring doc, I learned by using the #CrossOrigin annotation by default accepts all origins. This means my API should accept requests from all external resources. But apparently this is failing with a React "fetch" request. From the research I'm doing, I think I might need to send a header back, but I don't really know why/when I need to do this.
Why is Postman able to bypass CORS issues? Even before I enabled CORS server side, requests through Postman worked as expected.
Because Postman go through Http without any CORS policy. It doesn't need any policy. See here. And, possible that would be helpful.
Update excuse me.
I carefully read that article and now I don't clear understand your question.
First of all, CORS can be only filter and you won't send in response any information about this.
Also, you can send in response like headers information about your policy.
Please read that and that.
If I am incorrect,please correct me
Is there a way to localize messages in Java PlayFramework 2.2.0 in AJAX calls ?
Now I am make calls and hardcode messages (#Mesages("message-id")(lang)) by checking of the languages used per a page, but I am pretty sure there is a better way to do it.
Thanks in advance,
Simeon
The thing you are trying to do seems to be impossible, as your code is trying to get the data from Message file in configs which is done at the time of rendering that view. So scala is compiled on server side and you are trying to make the request for particular message in AJAX which is javascript code and client side execution.
Alternate solution for this is create an Post api for it which takes message-id as parameter and returns data from message file in configs through ajax call.
Here is the situation. I have received a WSDL (and included XSD) from someone that is generated by an Apache/Tomcat server (Java). The company i do a project for, prefers .NET so i used wsdl.exe to generate a partial class and created the webservice.
Then I created a .NET client (in this case I am using VB.NET) that has a web reference to the java wsdl. This works fine. Then I change the url using code and make it point to my newly created .NET service but i cannot seem to get it to work.
Doing it the other way round, also doesnt seem to work.
Been fiddling a bit with the namespaces and the service name but can't seem to crack it. Keeps giving me an error about HTTP header unable to find . as a method. This indicates a transport problem.
I really do not want to revert to plan B, being the creation of a Java Webservice and then linking this to the .NET environment. I know this will work since you will never have to change the urls.
Any suggestions ?
So to summarise you have:
SERVER SIDE: java, WSDL: java generated
.NET client -> java server - WORKS .NET client -> .NET server -> FAILS
If thats the case this has not much to do with Java!
But I do know as I aluded to earlier that .NET servers are fussy about the soap action header.
Is there a soapAction in your WSDL?
If so, you need to send that value, but I don't know how to do this in .NET (Google would be your friend here).
If not, check out the comments in this question for how to determine the required soap action header value: stackoverflow.com/questions/2262781/soap-action-wsdl
After a bit of searching through the devine knowledge base (Google), i have managed to get this fixed.
In addition to being very carefull in specifying the portnames (the default ones are not always what is requested so you need to override it) but most importantly, i found that adding
as part of the asm class header solved my problem. Now all I need to do is find out why?
But trust me, it works...
I found the solution here
One desktop application needs to get some services from server.
For example sending some parameters and receiving some result.
Imagine implementing a solution by Java Servlets, in a way that the app sends the parameters to the servlet (POST) and receives the result in XML.
Does this approach have any security issue in compare with web-services (Soap / Restful) ?
Thanks and sorry if the question is a bit general.
I don't think so. But personally I would still go over REST, mainly because it would be easier to maintain and update if needed. Also probably easier to test and implement.
As long as your solution has suitable authentication (username/password) and takes place over SSL, it's no less secure than Web Services/SOAP. And indeed you might find it a simpler solution to implement.
The security issue is the same for both solutions because it's http but I won't do the post thing because it's not structured properly, meaning it's client dependent and not using a standard. If you don't like XML, you can try JSON.