I'm a requesting a url with fetch in my node app and the response status is 464 (without responseText and without any error message). But I could't find any info about that.
Also if I request the same url with my browser (Chrome) then it works fine (no need to send any cookies or auth, it works in incognito window too)
What could be causing this?
EDIT: seems to be a problem with AWS Load Balancer, my problem is exactly this:
https://forums.aws.amazon.com/message.jspa?messageID=964799
But there's no solution in that post, so maybe could be helpful to put it here if someone knows the problem (I'm suspecting is related with HTTP 2.0 but not sure, could it be?)
Response Header in Node is:
Server=awselb/2.0
Content-Length=0
HttpCode=464
But in Chrome:
server: nginx/1.18.0
I had this issue just today. My target group was configured for HTTP/2, but, the backend service was not prepared for that traffic. So, when I rebuilt the target group using HTTP/1.1, traffic began to function as expected.
When creating a target group, the options presented to me for HTTP protocol options were (as shown in the AWS Console):
HTTP/1.1
Send requests to targets using HTTP/1.1. Supported when the request
protocol is HTTP/1.1 or HTTP/2.
HTTP/2
Send requests to targets using HTTP/2. Supported when the request
protocol is HTTP/2 or gRPC, but gRPC-specific features are not
available.
Related
Cannot load Apollo Server on safari. It returns an error that reads.
Safari does not support network requests from Studio on HTTPS to your local HTTP endpoint, so we cannot introspect your endpoint.
There are a couple solutions:
Visit this page from a browser that supports HTTPS requests to local HTTP endpoints, like Chrome or Firefox.
Set up an SSL certificate for your local endpoint.
Decided to try the second solution by spinning up ngrok. Which also returns a [Error] Fetch API cannot load https://7676-576-98-1-248.ngrok.io/ due to access control checks.
I am passing the Access-Control-Allow-Origin and Access-Control-Allow-Credentials Headers.
Any guess on what can be done?
Need some help to dig deeper into why IIS is behaving in a certain way. Edge/Chrome makes an HTTP2.0 request to IIS, using the IPv6 address in the header (https://[ipv6]/) which results in the server generating a 302 response. The ISAPI filter makes some mods to the 302 response and replaces the response buffer. IIS drops the request/response and logs in HTTPERR log:
<date> <time> fe80::a993:90bf:89ff:1a54%2 1106 fe80::bdbf:5254:27d2:33d8%2 443 HTTP/2.0 GET <url> 1 - 1 Connection_Dropped_List_Full <pool>
Suspect related to HTTP2.0, when putting Fiddler in the middle, it isn't HTTP/2.0 anymore, it downgrades to HTTP/1.1 and it works.
When using an IPv4 address, it works. In either case the filter goes through the identical steps. There is no indication in the filter that anything went wrong.
Failed Request Tracing will not write buffers for incomplete/dropped requests that appear in HTTPERR log.
Is there a place where I can find out more detailed information about why IIS is dropping the request?
I did the network capture, and looks like browser is initiating the FIN tear down of session.
Do you use any load balance or reverse proxy before request get in IIS? This error indicates that the log cannot store more lost connections, so the problem is that your connection is lost.
If you use load balance, web application is under heavy load and
because of this no threads are available to currently provide
logging data to HTTP.sys. Check this.
Or before IIS response to client, client has closed the request but
IIS still send response. This is more likely to be a problem with the
application itself not IIS and http.sys. Check this.
One thing I noticed is if you change http2 to 1.1, it can work well. The difference between http1.1 and 2 is performance.
HTTP/1.1 practically allows only one outstanding request per TCP connection (though HTTP pipelining allows more than one outstanding request, it still doesn’t solve the problem completely).
HTTP/2.0 allows using same TCP connection for multiple parallel requests
So it looks like that when you use http2, one connection includes multiple requests and application cannot handle these requests well, especially the request of image.
Aother thing is failed request tracing can catch all request and response, including status code is 200 and 302.
In our project we're using 2 servers: 1 as a PROD API server and 1 as a proxy(actually nginx is used for that)
The proxy server uses HTTP/2 as well. In one scenario the proxy may get response from prod API server and replace PROD links by Proxy's and then return that to the client.
In that case we can catch the "net::ERR_SPDY_PROTOCOL_ERROR 200" error. I googled little bit about that issue, but it looks like it may be few reasons for that error.
In my case it occurs only when we replace hosts(modify the response from the PROD before sending it to client)
Can someone describe what actually the "net::ERR_SPDY_PROTOCOL_ERROR 200" means and maybe best practices to avoid that?
HTTP/2 is derived from the earlier SPDY protocol, that's probably why the error message doesn't mention HTTP/2 at all.
One of the reasons why you may see the ERR_SPDY_PROTOCOL_ERROR message is an invalid HTTP header coming from the server. Perhaps your proxy is making some change to an HTTP response header which is making it invalid/malformed?
Try to disable HTTP/2 on your proxy server and see if the error goes away. If it does, inspect the response headers and make sure they are valid. I suspect your proxy server is malforming the response.
We met similar issue today when running the reverse proxy server using docker image: nginx:1.16.0-alpine. After changing to use nginx:1.16.0, this issue was solved.
We are working on an express/react application which is using websockets through https to fetch the data and display it on the front end. The app is working as designed on every browser except Firefox. It turns out that Firefox resolves the Request URL to "https://example.url" instead of sending "wss://example.url", which is the default behavior that works on every other broser. This in turn causes problems on the server during load balancing, and the server simply returns a 404 http error code.
I have already tried editing the about:config page in firefox regarding websockets and urlbars, to no avail. (although that would not count as a solution, since we cannot force our clients to do the same)
Is there a way to disable said behavior on Firefox or force it to use wss?
We are using ws node.js websocket library on both server and client.
I'm developing a tool for checking the integrity of links in a web page.
I've noticed that various Instagram URLs will return a HTTP 500 response in cases where if one were to visit the given URL in a browser one would get a HTTP 200 response accompanied by the expected resource.
This is when requesting regular Instagram URLs as one would do as a browser user and not when using the REST API.
A typical request/response using cURL:
curl -v http://instagram.com/p/YKTkxHBA-P/
* About to connect() to instagram.com port 80 (#0)
* Trying 54.225.159.246... connected
> GET /p/YKTkxHBA-P/ HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: instagram.com
> Accept: */*
>
< HTTP/1.1 500 Server Error
< Cache-Control: no-cache
< Content-Type: text/html
< Date: Tue, 15 Oct 2013 08:31:09 GMT
< Server: nginx
< Content-Length: 87
< Connection: keep-alive
<
<html><body><h1>500 Server Error</h1>
An internal server error occured.
</body></html>
* Connection #0 to host instagram.com left intact
* Closing connection #0
I did for some time get HTTP 200 responses in such cases but am now consistently getting HTTP 500 responses.
This is all specific to a given host; such URLs, even when sending requests with cURL, will return HTTP 200 responses from other machines.
Due to this being specific to the host sending the requests I suspect a form of rate limiting or request filtering by IP is going on, however I can find no documentation to the effect.
Will Instagram officially return a HTTP 500 response as above due to a given IP being denied access?
This is an IP rate limit. If you want to skip the part where you contact Instagram and wait for the monkey crew they have working over there to fix the problem, simply assign 1000 IPs to your server and loop through them randomly for your requests. You won't see anymore 500's.
Cheers.
I've received a mail from Instagram support just yesterday.
...
Hi,
We made some changes to our server configurations, can you please check if you are still seeing the 500 errors?
Thanks,
...
..well I was 100% certain that those 500ers didn't come from IG's IP rate limit because they weren't returned beforehand either.
I've been checking the logfiles and found a couple 502 (Bad Gateway) and "host unreachables", though no more 500 per se, after 2014-04-14 18:28:56 (PST).
Looks like they've finally sorted it out after nearly a month... ^_^
I had the exact same problem - unfortunately there is no way around it. This happens because of two many requests. At first I thought it was my IP or possibly my UDID until I signed into my app from my own phone and from my home IP but using a different Instagram id and it finally worked as expected again. Eventually, I could use my own ID again as time went by but with limited requests. I am not exactly sure how the algorithm works but the more time that went on the more requests I could use again.
Also, this is in real-time on an actual iPhone in an actual app - not on the iOS sim or Instagram API console, FYI.
Main Point: The request limit is based off the user (5000 requests per hour per user)...there is no IP rate limit.
Hope this helps :)
Clayton
I have the same problem. As i've rad, you have to get an extra access to API, I mean the Sandbox mode in your application does not allow you to use all the API. To get extra premissions go to client preferences, tab "premissions".
It seems to be related to curl version, I also experience the same problem with v 7.22.0 on 4 different machines 10 different ip's, while v7.30.0 and v7.19.7 are working like a charm.
Currently investigating further more.
I'm almost 100% sure this happens because the domain/IP address is blocked from the Instagram API.
Reason:
Works to get the JSON in the browser. Doesn't work to get with cURL from webservice.
I copied my exact application from my primary domain (were the application doesn't work) to another domain. Same application worked.
The strange thing is that you get a "500 Internal Error" back and not a message "Your IP is blocked".