What if I send off a GET/POST request and I get hit by a Connect timeout (not read timeout) and retry the request after?
Will the old request be cancled also on the server or will it maybe still arrive at the server at a later time and executed on server?
Also if we do not get hit by connect timeout but to get the response just takes longer it should mean the request arrived at the server but is probably still being executed on the server right? So we should wait until response is recieved since we etablished the connection for sure?
Thank you in advance!
Related
How can I determine when a flask server is ready to receive traffic?
For example, I have server A, inside a dockerfile, that sends a request to an already running server B, announcing its existence upon the container being run.
However once the already running server (B) recieves that request, it tries to send data to one of server A's routes, receiving the error: Failed to establish a new connection: [Errno 111]
Is there a flask or external resource that can send a request in the server when it is ready to receive resulting traffic?
I just pull the server state by sending a simple GET request:
#app.route('/srv_status', methods=['GET'])
def get_srv_status():
return 'OK', 200 # just means we're on air
If it replied, that means the server is ready to process the requests.
Additionally, it can serve for monitoring purposes.
PS: it's been a while after your question. It would be interesting to learn how you've solved the problem.
I'm using gRPC to call a service in client. After I set up channel:
channel = grpc.insecure_channel('server_url:service_port')
stub = Client.Stub(channel)
It works pretty good. However, if there's 5 minutes not using the client to send request, then the next request will get error message:
grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with (StatusCode.UNKNOWN, Stream removed)>
Unfortunately the gRPC retries functionality when the channel breaks is still work in progress and not fully available yet. One thing you could do as a workaround is to write an interceptor to retry automatically if it sees such error.
I wrote a web scraper using requests module. I open up a session and send subsequent requests using this session. It has 2 phases.
1) Scrape page by page and collect id's in an array.
2) Get details about each id in the array using requests to an ajax server on the same host.
The scraper works fine on my Linux machine. However when I run the bot on Windows 10, phase 1 is completed just fine but after a couple of requests in phase 2 python throws this exception
File "c:\python27\lib\site-packages\requests\adapters.py", line 453, in send
raise ConnectionError(err, request=request)
ConnectionError: ('Connection aborted.', error(10054, 'Varolan bir ba\xf0lant\xfd uzaktaki bir ana bilgisayar taraf\xfdndan zorla kapat\xfdld'))
What is different between two OS's which causes this? How can I overcome this problem?
Having modified my request code like below using retrying module had no positive effects. Now script doesn't throw exceptions but simply hangs doing nothing.
#retry(wait_exponential_multiplier=1000, wait_exponential_max=10000, stop_max_attempt_number=7)
def doReq(self, url):
time.sleep(0.5)
response = self.session.get(url, headers=self.headers)
return response
I still don't know why this problem occurs only in Windows. However, retrying decorator seems to have fixed the problem of socket error. The reason why the script hangs was due to the server not responding to a request. By default requests mode waits forever for a response. By adding a timeout value requests throws a timeout exception and retry decorator catches it and tries again. I know this is a work around rather than a solution but this is the best I've got right now.
I am trying to make a server in python using sockets that I can connect to on any web browser. I am using the host as "localhost" and the port as 8888.
When I attempt to connect to it, the stuff I want to be shown shows up for a split-second, and then it goes away with the browser saying "The connection was reset".
I've made it do something very simple to test if it still does it, and it does.
Is there a way to stop this?
import time
import socket
HOST = "localhost"
PORT = 8888
def function(sck):
sck.send(bytes("test"),"UTF-8"))
sck.close()
ssck=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
ssck.bind((HOST,PORT))
ssck.listen(1)
while True:
sck,addr=ssck.accept()
function(sck)
Probably the same problem as Perl: Connection reset with simple HTTP server, Ultra simple HTTP socket server, written in PHP, behaving unexpectedly, HTTP Server Not Sending Complete File To WGET, Firefox. Connection reset by peer?. That is you don't read the HTTP header from the browser but simply send your response and close the connection.
tl;dr
your function should be
def function(sck):
sck.send(bytes("HTTP/1.1 200 OK\n\n<header><title>test page</title></header><body><h1>test page!</h1></body>"),"UTF-8"))
sck.close()
With a server as simple as that, you're only creating a TCP socket.
HTTP protocols suggest that the client should ask for a page, something like:
HTTP/1.1 GET /somepath/somepage.html
Host: somehost.com
OtherHeader: look at the http spec
The response should then be:
HTTP/1.1 200 OK
some: headers
<header></header><body></body>
I'm new to stack overflow and socket programming. Thanks in advance for your help!
A little background: I am trying to implement a simple python server. I am trying to connect through TCP and am just trying to return the some parsed text from the request (I am trying to send back the text variable "message").
However, it seems that even after I close the connection, the server side socket accepts some random input called "/favicon.ico" and I am not sure where this is coming from. This loop accepts "/favicon.ico" a few times before returning to the state where it is waiting for a connection.
Does anyone know what is going on?
Here is my code:
#import socket module
from socket import *
serverSocket = socket(AF_INET, SOCK_STREAM)
#Prepare a sever socket
serverPort = 10016
serverName = '192.168.56.101'
serverSocket.bind((serverName,serverPort))
serverSocket.listen(0)
while True:
#Establish the connection
print 'Ready to serve...'
connectionSocket, addr = serverSocket.accept()
message = connectionSocket.recv(4096)
filename = message.split()[1]
#f = open(filename[1:])
print filename
connectionSocket.send(message)
connectionSocket.close()
print '\nYou got to this line\n'
-------------------------------------------------------------
Here is my client-side request: http://192.xxx.56.101:10016/sophie.JPG (stack overflow made me x out the IP)
And my client-side output, which seems to be returned alright:
GET /sophie.JPG HTTP/1.1
Host: 192.168.56.101:10016
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
-------------------------------------------------------------
And here is my server-side output (print statements):
name#name-VirtualBox:~/Documents/python_scripts$ python server2.py
Ready to serve...
/sophie.JPG
You got to this line
Ready to serve...
/favicon.ico
You got to this line
Ready to serve...
/favicon.ico
You got to this line
Ready to serve...
/favicon.ico
You got to this line
Ready to serve...
----------------------------------------------------------------------
I would have expected the output to simply be the first four lines:
Ready to serve...
/sophie.JPG
You got to this line
Ready to serve...
-------
I expected only these four lines back since the server should return to its waiting state after the connection is closed. However, it is still accepting some input called /favicon.ico and running through the loop a few more times before it goes back to the waiting state.
Does anyone have an idea as to what is going on here?
Thanks!
----------------------------------------
Update:
Ok, so I added the line you suggested, and I see that the browser is sending these extra requests and that they are (according to you) getting queued.
In addition to that, I also changed the line:
serverSocket.listen(0)
to
serverSocket.listen(1)
and then my code runs as I would want it to. (Actually, I have tried it again now, and it does not run as expected. the /favicon.ico request is still being sent)
I guess I have a couple followup questions about what is happening:
Why is the browser making more requests for /favicon.ico when I have not asked it to (with the original code serverSocket(0)?
Now that I have allowed the server to listen to more than one socket connection, why do the bogus connection requests (/favicon.ico) disappear?
And thanks, I will read up on syn cookies as well.
Thankfully, your server is working as expected!
Try adding this to your code, after calling serversocket.accept(): print addr.
What's happening is this:
You start your loop, and you call accept(). You're waiting for a new connection to arrive on port 10016. You receive that connection, serve the response, and then close that connection.
Then you loop again - thus ready to accept another socket connection. This time, it's for /favicon.ico.
The addr variable tells you that each new socket connection (for foo.jpg, and favicon.ico) is happening on a different port - that is what accept() does.
Because your code can only handle one connection at a time, the browser's request for favicon.ico goes into a queue. That is, the browser has requested to connect to your server to fetch the favicon, but your server has not yet accepted that connection.
Now, theoretically, you should not accept any backlogged connections. But there is a catch! It turns out that if TCP syn cookies are enable on your kernel, this parameter is ignored. (How would you know this? Well, it helps that I've done a bunch of networking in C; Python abstracts away many of these details.)
Hope that helps!
Are you using Chrome perhaps : server socket receives 2 http requests when I send from chrome and receives one when I send from firefox ?
I had a similar issue with my node server. It is due to the following bug in Chrome. In summary, Chrome is sending a request for a favicon on every request. As, is likely, you aren't sending a favicon back, it requests one after every legitimate request.
Firefox, and most other browsers, also send out a request for a favicon when they first connect, but cache the result i.e. if there isn't a favicon returned first time, they don't keep trying - which is why you're only seeing a single request from Firefox. It seems Chrome is unfortunately a little too persistent with its favicon requestiness.