How should i solve this error on Real NGINX Server? When i was developing on local there was no error show with that. And it's only happen on Mobile and Tablet. Not happened on PC Browser. I searched in google and stackoverflow too but the problem solving is only one way. I've to give my project manager to different solving methods at least 2 - 3 methods. Because Server providers won't allow to config the NGINX config file so we can't use this method. Currently I found below method. Is there any other method to solve this error like adding some codes or something that we can use without server providers?
server {
# ...
large_client_header_buffers 4 32k;
# ...
}
Developing Platforms : NGINX, Cakephp 3.x
Related
I'm trying to deploy a react-django app to production using digitalocean droplet. I have a file where I check for the current environment (development or production), and based on the current environment assign the appropriate url to use to connect to the django backend like so:
export const server = enviroment ? "http://localhost:8000" : "domain-name.com";
My app is working perfectly both on development and production modes in local system (I temporarily still used http://localhost:8000 in place of domain-name.com). But I observed something rather strange. It's the fact that when I tried to access the site (still in my local computer) with "127.0.0.1:8000" ON THE BROWSER, the page is blank with a console error "No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' ....".
When I changed it back to "http://localhost:8000", everything was back working. My worry is isn't 127.0.0.1:8000 the same as http://localhost:8000? From this I conclude that whatever you have in the domain-name.com place when you build your react frontend is exactly what will be used.
Like I said, I'm trying to deploy to a digital ocean droplet, and I plan to install ssl certificate so the site could be served on https. Now my question is given the scenario painted above, what should be the right way to write the url in production? Should it be "serverIP-address", "domain-name.com", "http://domain-name.com", "https://domain-name.com" ?.
I must mentioned that I had previously attempted to deploy to the said platform using the IP-address in the domain-name.com place. After following all the steps. I got a 502 (Bad gateway) error. However, I'm not saying using Ip address was responsible for the error in that case.
Please I would appreciate any help especially from someone who had previously deployed a react-django app to the said platform. Thanks
From this I conclude that whatever you have in the domain-name.com
place when you build your react frontend is exactly what will be used.
Not exactly true, the domain from which the react app is served will be used. If you build it local and upload it to the server and configure domain.com to serve it, then domain.com will be used for cors. The best idea is to allow all CORS until your project is deployment ready. Once done, whitelist the domain.com
The solution actually lies in providing the host(s) allowed to connect to the Back-end in the setting.py file like so: CORS_ALLOWED_ORIGINS = [ domain-name.com, https:domain-name.com , ... ] etc. That way, you wouldn't be tied to using the url provided in the react environment variable. Though I have not deployed to the server, my first worry within the local machine is taken care off.
I have an AngularJS / Strongloop project. The AngularJS part of the code is not hosted at the same location as the Strongloop project and as a result I'm running into a CORS issue. I have done a lot of reading on this issue, however I can't figure out how to solve it.
As far as I can tell, my issue is on the server side. See picture below.
I can't figure out how to configured Strongloop to be set to...
"Access-Control-Allow-Origin": "*"
Should I be trying to solve this a different way using Strongloop's built into ACL? Can someone point me to where I can correct the header for the API in Strongloop?
Below are some relevant article to the issue as I understand it.
http://blogs.telerik.com/kendoui/posts/11-10-03/using_cors_with_all_modern_browsers
how to handling CORS over $http in Angularjs1.3
So as frustrating as this was, I got it figured out. Turns out a detail I left out in my original post was that this application was built using two separate instances of Cloud 9 (http:c9.io), one for the client side and one for the server. I did this because it modeled the way the application was going to be installed in it's production environment. The issue was something to do with Cloud 9, when I ported this application to two different servers (that are un-related to Cloud 9), the issue was immediately resolve with no code changes at all to Strongloop or AngularJS.
That is really too bad, because up until this point I had been loving using Cloud 9. Guess I'll try codebox.
Below is a screen shot of the response header when ported to a non-Clould 9 instance. As you can see there is no longer the restriction on the Access-Control-Allow-Origin which was causing the problem
I have been recently stuck into a strange issue, thrown by a Multi platform Hybrid App in Visual Studio App.. My Development Environment details are as follows :
Visual Studio 2013 Release 3
Cordova 4.0
Angularjs 1.4
Ionic 1.4
Nokia Lumia 1320 [Windows 8.1 OS]
I have a web app that will be interacting with the mobile app, deployed on a server machine that can be accessed both by an internal enterprise network, as well as from internet.
Now the problem is, when i am [the mobile device is] connected to the internal network, the $http call fails with a status code of 0. Internal dig down reveals that the actual returned status code is -1.
However, when i switch over to mobile data in the phone, the ajax call goes smooth and finishes successfully. Now, if i switch back to internal network, it again starts working perfectly. !!!!
The http call is quite simple and uses promise API... I also have some request interceptors.
Any explanations for this strange behavior, or more appropriately a solution for the same ??
After Scratching my head for over 2 days, i was finally able to conclude that it was my browser that was the culprit.
As i said, i was using Windows Phone 8.1, which uses Internet Explorer 11 as the default rendered. Also, My Web server was actually behind a Proxy Server [Apache HTTP].
Now, the Real problem was that the ajax call was returning response status code as 0. And the reason for that was that The Ajax Call was being suspended by The Apache HTTP Proxy Server, because of some tunneling issue. Please note that this was specifically happening with IE11 and Apache HTTP Server.
This was happening since I was using POST request on a HTTPS Based Proxy Server.
Now the solution is too non-technical, but that's what saved my life. In order to save your life from this issue, You must
1. Either convert your POST Request to GET Request
2. Or Before making a POST Request to the Server, make a GET Request to the same server.
In my case, i went with the second approach and it saved my life. Posting this as answer so that it saves someone else too.
You can refer to the following links for more details.
IE10/IE11 Abort Post Ajax Request After Clearing Cache with error “Network Error 0x2ef3”
Making XHR Request to HTTPS domains with WinJS
I'm doing https web requests in silverlight using "WebRequest"/"WebResponse" framework classes.
Problem is: I do a request to an url like: https://12.34.56.78
I receive back a versign signed certificate which has as subject a domain name like: www.mydomain.com.
Hence this results in a remote certificate mismatch error.
First question: Can I somehow accept the invalid certificate, and get the WebBresponse content ? (even if it involves using other libraries, I'm open to it)
Additional details: (for those interested on why I need this scenario)
I'm trying to give a client access to a silverlight app deployed on a test server.
Client accesses the silverlight app at: www.mydomain.com/app
Then I do some rest requests to: https://xx.mydomain.com
Problem is I don't want to do requests on https://xx.mydomain.com, since that is on our productive server. For this reason I use https://12.34.56.78 instead of https://xx.mydomain.com.
Client has some firewalls/proxies and if I simply change his hosts file and map https://xx.mydomain.com to 12.34.56.78, web requests don't resolve to the mapped IP.
I say this because on his network webrequests fail if I try that, on my network I can use the hosts changing without problems.
UPDATE: Fixed the problem by deploying test releases to an alternative: https://yy.domain.com and allowing the user to configure for test purposes, the base url to which I do requests to be: https://yy.domain.com.
Using an certificate that contained the IP in the subject or an alternative subject would've probably worked too, but would have cost some money to be issued by a certified provider and would not be so good because IP's might change.
After doing more research looks like Microsoft won't add this feature too soon, unless there's a scenario for non-testing/debugging uses.
See: http://connect.microsoft.com/VisualStudio/feedback/details/368047/add-system-net-servicepointmanager-servercertificatevalidationcallback-property
I am a DBA, not a developer, so forgive me if this is a silly question. But we are having issues with a SQL Server 2005 Web Service end point. On the local network I am able to add the reference in Visual Studio 2010 with out any issues. It uses digest as the authentication scheme.
However, when anyone tries to add the web reference on another network, such as a developer in New Zealand (we are in Dayton, OH USA) he receives this error:
There was an error downloading
'http://server.domain.net:1280/release-single-address?wsdl'. The
request failed with HTTP status 505: HTTP Version not supported.
Metadata contains a reference that cannot be resolved:
'http://server.domain.net:1280/release-single-address?wsdl'. The
remote server returned an unexpected response: (505) HTTP Version not
supported. The remote server returned an error: (505) Http Version Not
Supported. If the service is defined in the current solution, try
building the solution and adding the service reference again.
Again, this works in Visual Studio as Right Click add Reference -> Advanced -> Add Web Reference when done on the local subnet as the server.
When done on any other network the service does not import. We have tried it w/o any proxy. There is a cross domain trust involved but that does not seem to be the issue as the error occurs using accounts from either domain. When I download the raw XML to my hdd I can use that to create the web reference. I believe firmly this is some sort of transport layer issue, such as a proxy, but captures when the proxy server settings are disabled are not conclusive.
Today, years after I posted this question, we finally found the answer to this question. It was not a Squid proxy server as we had come to believe. We continued experiencing issues like this with various web services/sites. The last straw was when we finally needed to deploy an SVN server that was used by multinational software engineering teams. Every single member of the different Ops teams we spoke to swore to us there was nothing between the sites that could break our services.
By a stroke of luck the company's Chief Information Security Officer was visiting our site and a colleague happened to run into him and asked about the issues we were having and what might be the cause of it. He said immediately that there were Riverbed appliances doing caching and layer 7 inspection on all WAN traffic. We finally managed to catch these devices in the act of attempting to "normalize" HTML and XML and we were able to perform a capture of data coming from a machine in New Zealand. We performed a diff on HTML pages that were served as well as XML coming from a web service to compare how it looked on the local network vs. across the WAN. In the pages/XML that were being served across the WAN the closing tags were inserted that were not needed or that actually made the XML malformed. Some tags were even commented out entirely if the appliance didn't know what to do with them. And the smoking gun? A custom header...
X-RBT-Optimized-By: cch-riverbed-1 (RiOS 6.5.6a) SC
"Optimized" You keep using that word, but I do not think that it means what you think that it means.
I'm not a pro of SOAP with VS but it may be that version of SOAP is incompatible with sql server 2005?
If I recall correctly, there is two versions of SOAP: 1.1 and 1.2.
Check the HTTP GET command format is correct?
HTTP GET http:// mydomain.com HTTP/1.1\
note there is a SPACE between 'http://' and 'mydomain.com'. The server can not match this format. The result is 505
I am not sure but, I think you should check your firewall or your IIS configuration.