I have been running a python script on an Amazon EC2 instance. It runs fine for a while and then I get this error:
Invalid JSON error message from Binance:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>503 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
This distribution exceeded the limit on requests per second.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: uQnEmv-kXx0j2v3WdxnbrkBlJDdI33fduqBNYhNoIVfv10G1_LZS1Q==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>
I am requesting the data every 1 minute.
I can't find any information about this error.
Related
I'm currently working on a Web API with Flask. The idea is that i get a Json File and i return one after the work is done.
The code is working (it worked before) but I'm currently getting this Error on Postman :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>400 Bad Request</title>
<h1>Bad Request</h1>
<p>Did not attempt to load JSON data because the request Content-Type was not 'application/json'.</p>
and on the command line i get:
"POST /json HTTP/1.1" 400 -
code 400, message Bad request syntax ('{')
"None /json HTTP/0.9" HTTPStatus.BAD_REQUEST -.
Has anyone an idea what that means ?
Make sure the api server is not problematic.
The answer is in the response message. You made the api request without the appropriate Content-Type header. Just add it and it should work, if the api server has no other issues.
Is there an accurate way to distinguish between a GET request directly to a file :
website.com/file.css
and a GET request to the same file but when loading a page that includes:
<style rel = "file.css">
As far as I can tell, the HTTP requests are pretty much identical.
Are there any solutions which don't involve:
Monitoring the server request logs (timing / sequence based).
Adding in GET parameters, e.g. file.css?r=dgsfgfgd
Using CSP reporting.
It only occurs on a single PC.
Error line :
XML Parsing Error: syntax error Location: http://gall.dcinside.com/board/lists/?id=baseball_new5&page=1 Line Number 1, Column 1:
Column 1 :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Error occurring site : http://gall.dcinside.com/board/lists/?id=baseball_new5&page=1
As you can see, the document type is set as HTML while the response data is XML. Why? And how do I fix this?
The document type is XHTML, which can be taken as either traditional HTML or HTML expressed in XML format. This error could occur if your browser takes it as the latter (though I don't understand, with this message, what it doesn't like with Line 1, Column 1).
I can't reproduce this behavior, but you could snoop the exchange between the browser that shows the problem, and the website. Use your browser's Network developer tools for that.
The website probably chooses to answer to this browser, with a content-type set as application/xhtml+xml, which your browser would then parse as XML and trigger XML-related errors. It probably chooses to do so because your browser sends unconventional errors, which could be because of uncommon extensions installed or some uncommon configuration. Anyway, snoop the exchange, try to confirm or at least post what you observed.
Sometimes when accessing the Forge Derivative Service API via
GET https://developer.api.autodesk.com/derivativeservice/v2/manifest/dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6c3RlbW4vNTcwMzBkMzBjNzFkZWVmNDBkNjViNDAxLTBCOTlVamtJMXBnN2FkbE16UzJKSExVbzNjV3MtMEI5OVVqa0kxcGc3YWRHOTJlbVJtTnpablJ6TnhRV2N5V1hOT05qZEdPV2xwYVhoclBRLXVuZGVmaW5lZC5kd2c
I get the response
<HTML><HEAD>
<TITLE>Bad Request</TITLE>
</HEAD><BODY>
<H1>Bad Request</H1>
Your browser sent a request that this server could not understand.<P>
Reference #7.425832b8.1500624784.0
</BODY>
</HTML>
How can I find out what it was about my request that the server did not understand. This is a simple GET request so I'm not sure what I am doing so that my request is not understood.
First, there is no endpoint like you are describing (see list): derivativeservice/v2/manifest/:urn doesn't exist, aren't you missing something? Which endpoint are you trying to call? Maybe manifest?
Second, when I base64 DECODE your URN, I'm getting:
urn:adsk.objects:os.object:stemn/57030d30c71deef40d65b401-0B99UjkI1pg7adlMzS2JHLUo3cWs-0B99UjkI1pg7adG92emRmNzZnRzNxQWcyWXNONjdGOWlpaXhrPQ-undefined.dwg
This undefined at the end is a bit suspicious and may be causing this problem. Can you double check the URN before encoding it? If that's a file on a bucket, seems incomplete/incorrect anyway.
From ESB our api is making a call to the downstream service which in case of negative scenario is returning
`<html>
<head>
<meta content="HTML Tidy for Java (vers. 27 Sep 2004), see www.w3.org" name="generator"/>
<title/>
</head>
<body>invalid address type</body>
</html>`
but when we log inside esb we see this
QUIgaXMgaW52YWxpZCBhZGRyZXNzIHR5cGU=
Also when the message is send to the caller using respond , the caller gets HTMl again.
We had enabled the following in axis2
`<messageBuilder contentType="text/html"
class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
`
We want to transform the response into JSON and want to map body in the response before sending to the caller .
The HTML content will be treated as a XML segment by the ESB. SO you can perform any manupulation operation on this content. Can try the Payload Mediator or Enrich mediator with some XPath expressions.
we had observed that the content is coming as base64encoding string into the ESB, that was the reason we were not able to process it , so we did reqd decoding and processed as per our reqmt .