We are encountering errors when trying to use a web application, iframe, and proxy port in colab in Chrome.
First, we pick an unused port, then set up a server on that port.
Then, we create an iframe that connects to this proxy url:
server_url = eval_js(f"google.colab.kernel.proxyPort({port})")
The iframe itself is loading, but we see tons of network errors and the server is not properly connecting in colab. Many of the errors we see are grouped like this, with a 500 and 401, and don’t think we should be seeing this. It appears that there is a service worker intercepting our fetch call (a grpc-web+protobuf call), and when it encounters the 401 error from the server-side proxy, it translates it into a 500 that our application code sees. Are there any other details that we should know about in regards to the proxy/service worker that seems to be intercepting the calls?
Attached it a screenshot of Chrome's dev tools, showing the 500 and 401 calls. As you can see, a service worker handles the initial request, and appends a ?authuser=0 to the request before it goes to the server-side proxy.
The 500 response is empty, and the 401 response is below:
<html lang=en>
<meta charset=utf-8>
<meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
<title>Error 401 (Unauthorized)!!1</title>
<style>
*{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}#media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/logos/errorpage/error_logo-150x54.png) no-repeat;margin-left:-5px}#media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/logos/errorpage/error_logo-150x54-2x.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/logos/errorpage/error_logo-150x54-2x.png) 0}}#media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/logos/errorpage/error_logo-150x54-2x.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
</style>
<a href=//www.google.com/><span id=logo aria-label=Google></span></a>
<p><b>401.</b> <ins>That's an error.</ins>
<p> <ins>That's all we know.</ins>
It looks like the first unary grpc-web call will go through, but subsequent calls will fail - in our use case, the next call is server-streaming, but later unary calls also fail, so it doesn't seem to be specific to expecting h2 server-streaming responses.
Colab link:
https://colab.research.google.com/drive/1FGDlUi3Ibtffb9hoYCp27WCe7JLpQRl7?usp=sharing
We're confident that our server isn't sending the 401 reply (as it would use a grpc-status instead), and as far as we can tell, it doesn't even get the request, much less have the opportunity to respond.
We would expect to be able to connect to the server and continue communication.
Related
I am just starting to learn how to make requests to APIs using Javascript, and I have been stuck on the following for a few hours.
I used the following public API:
http://www.penguinrandomhouse.biz/webservices/rest/
The issue is that, when I was using XMLHttpRequest, I am always running into an error. At first I didn’t include the content-type in header I got a 404, and when I included it, the error I have got a CORS error.
The following is the code
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8"/>
<title>Request book</title>
<style>
...
</style>
</head>
<body>
<section class="preview">
<div id="return_content"></div>
</section>
<script>
let request = new XMLHttpRequest();
const url = "https://reststop.randomhouse.com/resources/authors";
request.open("GET", url);
let content = {
lastName : "Grisham",
}
request.setRequestHeader('Content-type', 'application/json');
/* I did not add this at first, but it seems like the
default content type for XHR is not what the API wants*/
request.send(JSON.stringify(content));
request.onreadystatechange = () => {
if (this.readyState == 4 && this.status == 200){
console.log(request.responseText);
/* let content_div = document.querySelector('#return_content');
content_div.innerText = request.responseText; */
}
}
</script>
</body>
</html>
The error message is as the following:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://reststop.randomhouse.com/resources/authors. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200
But I tried sending the request first with Axios in node.js with the following, it goes totally fine; so I assume it must be something wrong with my request. However, from my understanding the CORS policy should be set by the server, and it seems like from this post I cannot set Access-Control-Allow-Origin — it is supposed to be something provided by the server-side.
It seems like something is missing in the request but I really have no idea. Any help or hint would be appreciated!
It seems like I didn’t go through all the documents… I kept reading about the API but didn’t go through the CORS MDN page in detail.
Anyway I will just leave it here in case anyone need this in the future.
Quoted from MDN:
For security reasons, browsers restrict cross-origin HTTP requests initiated from scripts. For example, XMLHttpRequest and the Fetch API follow the same-origin policy. This means that a web application using those APIs can only request resources from the same origin the application was loaded from unless the response from other origins includes the right CORS headers.
I think this means the CORS policy is a way for the browser to protect itself from malicious scripts too, most likely the ones that aims for the cookies stored in browser.
What I found the most confusing is that the error message changed before and after I added content-type in header. What happened back there, was that I made a “simple request” without knowing it(from this post, the default content type is text-plain), which is why it didn’t trigger the CORS policy but only gave me a 404.
I am making HTTP request to Google Custom Search as specified in Documentation here
https://developers.google.com/custom-search/v1/cse/list
A couple of days ago everything was working fine, however, now search API returns 502 ERROR sporadically. Most of the search requests go thru but some return generic "That's an error" page
Is anybody else getting this?
Is anybody aware if there is a status page for Google Custom Search JSON service?
Here is the response body from JSON API
<!DOCTYPE html>
<html lang=en>
<meta charset=utf-8>
<meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
<title>Error 502 (Server Error)!!1</title>
<style>
{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px} > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}#media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}#media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}#media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
</style>
<a href=//www.google.com/><span id=logo aria-label=Google></span></a>
<p><b>502.</b> <ins>That’s an error.</ins>
<p>The server encountered a temporary error and could not complete your request.<p>Please try again in 30 seconds. <ins>That’s all we know.</ins>
We've been having the exact same issue in the past couple of days using the .NET client and it definitely seems to be on Google's side.
I "solved" this by adding a retry mechanism. When listRequest.Execute().Items fails, I catch the exception, sleep for a second and retry. So far is the only thing that worked.
I have developed my API and registered in mule API Manager.
When my API is down and trying to hit the API from Postman tool getting below error.
<html>
<head>
<title>504 Gateway Time-out</title>
</head>
<body bgcolor="white">
<center>
<h1>504 Gateway Time-out</h1>
</center>
<hr>
<center>nginx</center>
</body>
</html>
Ideally it should be 503 – Service unavailable. Any options to get error code 503 instead of 504 ?
If you API in API manager is down, there is nothing you can do. If your backend implementation is down you could do something will policies to override the status code.
But as your API in API manager is down, there is nothing in your control.
504 is still technically valid as nginx is acting as a proxy and it cannot reach your API.
But I would not worry about it. all API client should handle 5XX status code the same. As in 'Server Error' and can possibly be retried later.
Also with API down in API manager, the 504 should take a while to get a response back. So I would probably set a decent request timeout before reaching that point.
That really isn't in your control. The difference between 503 and 504 is that 503 means that your app-server has issues, while 504 means that the gateway you're using has issues.
For example, if I am using nginx as a gateway, and I'm redirecting to some app server. If the app server is down, then nginx will return 503.
If, however, the app server is unresponsive, or if nginx itself is failing (due to load, or other issues), the response will be 504.
In general, you shouldn't be worried about what the response is. 5xxs are treated roughly the same in most situations, and they mean server issues.
I am having one webservice to sync order data from Ipad offline app to live server. Sometimes webservice is working fine but sometimes it is not.
So when I am trying to call that webservice to resolve the issue through url using Postman, I am getting below error.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>414 Request-URI Too Long</title>
</head>
<body>
<h1>Request-URI Too Long</h1>
<p>The requested URL's length exceeds the capacity
limit for this server.
<br />
</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at ip-172-31-31-143.ap-southeast-1.compute.internal Port 80</address>
</body>
</html>
Please provide me the solution. Thanks in advance.
The Web server (running the Web site) thinks that the HTTP data stream sent by the client (e.g. your Web browser or our CheckUpDown robot) contains a URL that is simply too large i.e. too many bytes.
Typically Web servers set fairly generous limits on length for genuine URLs e.g. up to 2048 or 4096 characters. If your URL is particularly long, you can usually try shorter variations to see roughly where the limit is. If your long URL is indeed valid, then the Web server may need to be reconfigured to allow your URLs through. Understand that Web servers have to set some reasonable limit here, because they have to deal with badly programmed clients trying to give them huge garbage URLs.
Fixing 414 errors - general
This error seldom occurs in most Web traffic, particularly when the client system is a Web browser. The URLs in this case are typically standard hyperlinks found on Web pages. These links tend to be too large if they are simply wrong i.e. the Web page containing the link has been badly coded.
If your client system is not a Web browser, the problem can only be resolved by examining what the client is trying to do then discussing with your ISP why the Web server rejects the size of the URL sent by the client system.
I'm trying to use neo4j's REST API from an Apache Flex front-end. When my Flex app connects to the base URL (http://localhost:7474/db/data/) to discover other service URLs, it gets replies back in HTML rather than JSON format (just like if I enter the base URL into my browser).
In the Flex HTTP request, I've set the Content-Type and Accept headers both to "application/json" but it hasn't made a difference. I've also tried both GET and POST request methods.
I've verified neo4j is capable of sending JSON responses through a simple telnet window, so it must be "intelligently" formatting the reply based on something in the HTTP request. I'd thought the Content-Type and Accept headers would take care of it, though.
I realize the problem isn't technically in neo4j, but rather somewhere inside Flex's HTTPService (and supporting) classes, but I've been unsuccessful in working around the apparent bug/limitation.
Is there a way to simply force all such responses from neo4j to just be in JSON format?
Thanks,
Chris
* EDIT *
As requested below, here is the exact reply I'm getting in my Flex app:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head><title>Root</title><meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<link href='http://resthtml.neo4j.org/style/rest.css' rel='stylesheet' type='text/css'>
<script type='text/javascript' src='/webadmin/htmlbrowse.js'></script>
</head>
<body onload='javascript:neo4jHtmlBrowse.start();' id='root'>
<div id='content'><div id='header'><h1><a title='Neo4j REST interface' href='/'><span>Neo4j REST interface</span></a></h1></div>
<div id='page-body'>
<table class="root"><caption>Root</caption>
<tr class='odd'><th>relationship_index</th><td>http://localhost:7474/db/data/index/relationship</td></tr>
<tr><th>node_index</th><td>http://localhost:7474/db/data/index/node</td></tr>
</table>
<div class='break'> </div></div></div></body></html>
This is the same result I get if I just put the base URL in my web browser manually and retrieve it that way.
I figured it out. When I compiled and ran my Flex app as a browser-based app, it used the browser's native capability to request the URL, blowing away my customized Content-Type and Accept headers.
When I compiled and ran as an Adobe Air desktop app, it worked fine and I received the proper JSON response.
Likely this is a bug in Flash Player, as the documentation for the Flex HTTPService class doesn't give any limitation on changing Content-Type or other headers when running in a browser vs. Air.
-Chris