serving non-existent favicon.ico with staticfile throws error on refresh

Originally reported by: @wyuenho

---

So apparently Tree.mount() attaches a static handler for favicon.ico if the root doesn’t already have a handler for it without even looking at the config. If the config has a section for /favicon.ico, but the file doesn’t exist, refreshing the browser will throw and error in the errorlog with something like this:

[17/Jan/2010:01:30:00] HTTP Traceback (most recent call last):
  File "/Users/wyuenho/Documents/spiralup/spiralup/lib/python2.5/site-packages/CherryPy-3.1.2-py2.5.egg/cherrypy/_cprequest.py", line 606, in respond
    cherrypy.response.body = self.handler()
  File "/Users/wyuenho/Documents/spiralup/spiralup/lib/python2.5/site-packages/CherryPy-3.1.2-py2.5.egg/cherrypy/_cpdispatch.py", line 25, in __call__
    return self.callable(*self.args, **self.kwargs)
  File "/Users/wyuenho/Documents/spiralup/spiralup/lib/python2.5/site-packages/CherryPy-3.1.2-py2.5.egg/cherrypy/_cptools.py", line 150, in handle_func
    handled = self.callable(*args, **self._merged_args(kwargs))
TypeError: staticfile() got multiple values for keyword argument 'filename'

This obviously doesn’t even tell me what values it got, so the error message doesn’t even help. I’m not sure how to patch this because you need to obviously look at all the different kinds of dispatchers for the “/favicon.ico” key besides the default tree dispatcher, and I’m not familiar with all of them.

Reported by [e-mail]

---

• Bitbucket: https://bitbucket.org/cherrypy/cherrypy/issue/983

[webknjaz]

In #1623 @sanjaySP suggested to register a custom path for favicon and explicitly specify that in your HTML pages as a workaround.

[webknjaz]

With the monkey-patch from #1623 (comment) (which I don’t understand at all) , the traceback is gone.

That patch removes the duplicate argument. But it “cures” the symptom, not an underlying issue. It looks like the fix should be done on a different level, being more fundamental. The patch might hide other problems if they happen, which would then be impossible to debug.

To truly fix the issue, we need to understand the flow across different components of the framework and why this is happening. Otherwise patching random places would be harmful.

Basically, this is why I postponed the fix, it needs mode dedicated investigation first.