Issue with simple python server. socket.accept() accepts input /favicon.ico even after I (supposedly) close the socket

Question

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:

1. Why is the browser making more requests for /favicon.ico when I have not asked it to (with the original code serverSocket(0)?

2. 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.

Answer 1

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!

Answer 2

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.