The axios.post request doesn't work without proxy.
I am new in react js and using create-react-app
When I use proxy attribute in package.json and give it my http://url:port in my axios.post I start from /api/...
I do not need any config like headers or allow access. And I don't need to stringy data.
My back-end is java using Apache Tomcat and in back-end I have CORS filter that only allows application/json
requests. When I use postman if the header doesn't match , Apache refuses the request by 415 unsupported media type.
The problem begins from where I want to use npm run build. so there is no package.json and I should bring my full url to axios.post's url part : http://url:prot/api/..
Then I removed the proxy part from package.json
Since that I haven't seen any response from java or even it doesn't refuse the request in http monitoring or Apache Log part (in Netbeans)
I did two small things and something changed!
1-Adding JSON.stringfy before data
2-Adding headers Content-Type:Application/json
Now the request is observable in Netbeans (the back-end) BUT the messege is unsupported media type although i have added to axios.post's config(and itself caused the request received )!!!
there is some thing else : when I use the fire fox CORS enable adds on every things goes grate but only with that...
This is my first project. please explain like I'm 5! I do not know anything more!
Or if someone has any better way; is there any way i can use axios.post without package json proxy?
Related
I want to simulate a fake 404 status code from the backend to see how my website will behave.
I don't want to mock fake response status in the code I would like to use some tools.
Cause sometimes I want to test it on the production which has version x and I don't want to waste time downloading this code and checking if there it is working.
Just simply mock response header status code for some test value like 404 for the fast check.
I tried to use software like Requestly - chrome extension.
And configured it like :
Modify response for header status put value 404 for google.com site.
But when I open google.com site I got status 200:
Do you know how can I change the status code of the given request?
Maybe by using different soft?
Status is not an HTTP response header. Status Code is an HTTP response code and Chrome does not allow to modify the response code of a request. There are two possible ways to solve this using Requestly
1-Step solution using Requestly Desktop App (Reliable & Guaranteed to work)
You can use any MITM proxy to intercept the request and simulate the status code. However, given my experience with Requestly, I'd explain how you can do it with Requestly Desktop App
Install Requestly Desktop App,
Go to Rules Tab and Click on New Rule
Select Modify Response
Define the exact URL (or Pattern) and define the status code. That's it.
Screenshot
Demo
https://www.youtube.com/watch?v=nLcIZGmMAtQ&ab_channel=Requestly
Using Requestly Browser Extension (2-Step Process, Should Work in most sites but there could be some CORS Issues)
Install Requestly
Use Requestly Mock Server and create a new mock which serves 400 or 404
Use Requestly to set up a Redirect Rule which redirects your original request to the URL of your mock request
Here are a couple of examples using the extension
Simulate 500 in Twitter Create Tweet API
Simulate 404 in BlinkIt Search API
Footer Notes
Desktop App-based solution is more reliable and guaranteed to work while Extension-based solution has technical limitations and there may be some CORS Issues depending upon your backend So prefer to use Solution 1.
PS - I built Requestly (& still building it with lots of heart)
In DevTools on the Network panel, right click a resource and select Block Request URL or Block Request Domain.
Does that help in your use case?
Try using ModResponse: https://chrome.google.com/webstore/detail/modresponse/bbjcdpjihbfmkgikdkplcalfebgcjjpm. You can add "Replay response" on the URL that you want to replay, visit that URL, then open up ModResponse again to edit the HTTP status code. You can also use it to edit the HTTP response body and header as well.
I trying to create a freeboard dashboard. I have a Arduino with four sensors that send their informations by mqtt. So, I on Node-RED I gen a JSON to response get request in /saida.
[{"id":"3f699b5.c91f064","type":"http response","z":"c7d4e8c8.509218","name":"","x":1184,"y":589,"wires":[]},{"id":"a3ed6250.1d64","type":"json","z":"c7d4e8c8.509218","name":"","x":1120.5,"y":540,"wires":[["3f699b5.c91f064"]]},{"id":"971f41c1.a1265","type":"function","z":"c7d4e8c8.509218","name":"","func":"msg.payload = {\"temperatura\":\"25\"}\nreturn msg;","outputs":1,"noerr":0,"x":1015.5,"y":584,"wires":[["a3ed6250.1d64"]]},{"id":"ed9f7a2a.604728","type":"http in","z":"c7d4e8c8.509218","name":"http in","url":"/saida","method":"get","swaggerDoc":"","x":850,"y":582,"wires":[["5b40d38c.5cc7ec","971f41c1.a1265"]]}]
In this moment, I`m using a static JSON to make a test. I have a use the host like:
my-public-host:1880/saida -> {"temperatura":"25"}
I access it by a proxy, the JSON returns ok. On ping.eu port check, the port is open. I ensure that my host is public.
But on my freeboard, I add it as datasource, then it says "never" update and I can`t read the JSON info.
What I should do to solve it?
I solved my problem.
There is a bug in freeboard.io. the thingproxy.freeboard.io don't work. The the browser don't let the freeboard.io make AJAX request for other link that isn't https. Besides, the browser don't let make a AJAX request for an other host.
There is two solutions:
Use sitelock on your host and add Access-Control-Allow-Origin to you response headers.
Use a https proxy and a browser extension to allow cross access.
bye!
Correct.
If the data source is flask based app, you can follow this link below to make freeboard read.
https://flask-cors.readthedocs.io/en/latest/
I want to create a cordova generic client for debug purpose. but I face the cross domain request problem. My case is:
1. I deploy my source code (html code) on a web server A.
2. My backend data source is from server B.
3. I create a cordova app and run on the device or simulator. the App access the url from server A and open the app page, that work fine. but when my js code read data from Server B, all request is failed. I guess it's cause by cross domain restriction.
Any one have solution to resolve this problem?
Thanks!
Well, since your initial HTTP request goes through and HTML is returned, it seems that the connection from the Cordova is working, at least for server A.
What you could try is to upload temporarily "content" to server A which you try to fetch with AJAX calls.
If that succeeds, you can be sure that the fault is on server B and CORS works okay from front-end. In which case you could try to access the A & B from web client etc. to see possible differences in response headers. The server B is in that case probably missing Access-Control-Allow-Origin: * header. Try to add it to your server configuration or try JSONP. Also as a long shot, read your config.xml if you have only allowed connections to server A with
<access origin="<server A>"/>
in which case you obviously need to allow server B too.
If that fails, there is much less to work with and I can only suggest you to study resources like enable-cors.org which demonstrate how to actually allow CORS.
Can anyone tell me if it is possible to specify mime-type returned from a RESTful web service through the URL? I am trying to demo a simple service that I created to someone and I am just using a web browser (Chrome) to invoke the service. I am trying things like this:
http://localhost:8088/providers?mimeType={application/json}
http://localhost:8088/providers?mimeType=application/json
http://localhost:8088/providers?mimeType=json
None of these work for me - I just keep getting XML returned no matter what I select.
I found several posts related to this subject, but nothing with an answer about how to do this through a URL (I found some which talked about setting headers, but I am using a browser and don't have the ability to specify headers). I found this post:
REST Content-Type: Should it be based on extension or Accept header?
And that post linked to this: http://www.xml.com/pub/a/2004/08/11/rest.html
On the xml.com site, I found this text:
URI-Specified Representation [PS, AR]
A client can specify the representation using the following query string:
mimeType={mime-type}
A REST server should support this query.
So it seems that what I am trying to do should be possible, but I can't figure out how to make it work. Can anyone help?
Thanks.
To define the headers added to your request, you can use a Chrome extension like Postman.
Then you will be able to specify an Accept header to tell Talend to return json:
Accept: Application/json
New here. I've searched quite a bit for a working solution to my problem, but even though I have found posts with promising titles, none of the solutions have worked.
I am deploying an MVC2 web app to a client's server.
I did my development on Win2k8 Server, but they are running Win2k3 sever.
The app's only purpose is to receive some record ID information as HTTP parameters, check in the database for the status of the given record or records, and then return the status information as a simple string such as "Completed" or "Incomplete" in JSON format.
This getJSON code works fine in the development environment.
Inexplicably to me, on the client's server, the getJSON request receives a null response from the application.
There is no cross-domain action AFAIK... the result is the same from the client's server or from my machine via VPN.
In the MVC model's Json code, a common solution for people is to add the "JsonRequestBehavior.AllowGet" attribute to the Json result being returned. I did this long before trying to deploy it, and as I said, it has worked fine in the dev environment.
Using Firebug, I have watched the same request URL get sent to both my local server and the client server - the response headers from both servers are the same, but the response content from my server is shown as:
{"Result":"No Data"}
Which is what I want.
There is literally no content shown in the response from the client's server..? But the request gets an HTTP 200 code and is recorded as a success in the reponse's status attribute.
The response header content type in both situations is "application/json"
But wait, there is more!
If I manually enter the request to each server in the Firefox nav bar, and hit enter, in both cases it responds with:
{"Result":"No Data"}
Which is what I want. So why can I get the result I want from the MVC app on the client's server only when I hand-enter the request URL in Firefox, but not from the Javascript code?
I have tried forcing different output content types ... using the jQuery ajaxSetup method...
$.ajaxSetup({
async: false,
dataType: 'text'
});
or
$.ajaxSetup({
async: false,
dataType: 'html'
});
and again wtih 'script', and 'json'. I also tried the conversion options such as 'text json' or 'html json' or 'json text' and so forth.
Some of the posts I'm reading, and my gut feeling, though, suggest the problem is not the jQuery code making the request that is at fault... I don't see how the same jQuery request point to a different server running the same app would suddenly cause that server to send back a 'null' value.
By null, I want to be clear... I mean nothing is sent. There is no {} or {null} or any sign of JSON... just blank whiteness of non-existence :P
Even if nobody knows the answer, I would love some input perhaps suggesting where I should focus my sleuthing ... client or server?
If the problem is the server, it seems hard to really know that the MVC stuff is running 100% on the IIS6 server, but in general it seems to work. I have a different MVC app running on the client server which responds to the virtual paths, and generally runs the same as on dev machine.
I have found one thing ... the request headers are somewhat different? The Request Headers sent to the IIS7 setup include an "X-Requested-With: XMLHttpRequest", "referrer" , and "cookie" field/value.
I could guess that the lack of the "X-requested-with: XMLHttpRequest" in the IIS6 request headers is a clue, but I do not see then how the same javascript code pointing at a different server can generate different request headers itself. So how else are those being generated?
The javascript is embedded in an ASP.NET page, btw.
Oooh.. frustration!
Thanks for any input.
Odd Progress ... apparently there is some sort of issue with IIS6 handling the query. Although I have not payed any attention to JSONP, a post elsewhere suggested that sometimes use the "&callback=?" parameter at the end of a .getJSON request URL would force it into GET mode and that worked frequently for problems getting data from the server. So I did that... and it did work, sort of. The proper {"Result":"No Data"} was returned in response to the request... which seems good. However, the way that the JSONP callback works, it generates its own script to do the calling and fetching and interpreting of the incoming JSON. In this case, it interprets the JSON to need a label which it does not have, thus an error is thrown "invalid label" ... there must be some way to hack things to just deliver the JSON, but the whole required use of JSONP callbacks suggests that the server configuration is wrong, right? Or why does it work without JSONP for IIS7 and not IIS6?
Despite my not liking the callback JSONP solution, it appears to work ok. The error is still returned about an invalid label, but that does not appear to stop the remaining javascript from running... and so the application is working with IIS6 now. I have not tested the fix of using the callbacks and JSONP against IIS7 yet, but I expect it will work well enough.
Here is a link to the discussion that lead me to my current solution. I do still hope to find a more elegant solution, however.
NeoWin.net
Are you certain that your App Extension Mappings are set up correct?
Follow this article for running MVC2 on IIS6 and ensure all the different configurations have been done, that's probably the first step before going further and investigating specifics.
I'm really inclined to believe it's related to HTTP Verbs.