I'm guessing that GAE decides at launch time which file types it will serve
from which directories and that routes.py is unable to override the block at
request time. I'm basing that on the "blocking access" msg when Launcher
started and the 403's since those are issued when access is forbidden as
opposed to the file being non-existent. So it's possible that putting just
the right regex juju into app.yaml would allow serving the files w/o
explicitly naming them. But I may well be FOS on this one :-)
On Wed, Sep 15, 2010 at 7:49 PM, Jonathan Lundell <jlund...@pobox.com>wrote:
> On Sep 15, 2010, at 4:39 PM, Michael Ellis wrote:
>
> Problem resolved, thanks to suggestion from cfh. Added explicit
> favicon.ico handler
>
>
> That's good, but do we understand why the original didn't work? (Just
> curious.)
>
>
>
> - url: /favicon.ico
> static_files: applications/init/static/favicon.ico
> upload: applications/init/static/favicon.ico
>
> There's a bonus. It works without routes.py. That's handy because I
> didn't want to have to version control anything outside my app's directory.
>
>
> FWIW, I keep routes.py in myapp/private/ and copy (or link) it at
> installation time.
>
>
> Cheers,
> Mike
>
>
> On Wed, Sep 15, 2010 at 6:59 PM, Jonathan Lundell <jlund...@pobox.com>wrote:
>
>> On Sep 15, 2010, at 3:46 PM, Michael Ellis wrote:
>>
>> The error is reported by GAE Launcher, the test app you use before
>> deploying to GAE. Hence the OS X path. Nothing else seems wrong; the app's
>> pages render correctly etc.
>>
>>
>> I don't know. Does routes.py do the right thing for favicon.ico if you run
>> it on localhost? Do you *have* a favicon.ico in init/static?
>>
>> A question for Massimo: the stock app.yaml has:
>>
>> - url: /(?P<a>.+?)/static/(?P<b>.+)
>> static_files: applications/\1/static/\2
>> upload: applications/(.+?)/static/(.+)
>> secure: optional
>> expiration: "90d"
>>
>> Why does this have ?P<a> & b but use \1 and \2? Or is there some implicit
>> logic going on under the covers?
>>
>>
>>
>>
>> On Wed, Sep 15, 2010 at 6:16 PM, Jonathan Lundell <jlund...@pobox.com>wrote:
>>
>>> On Sep 15, 2010, at 2:53 PM, Michael Ellis wrote:
>>> >
>>> > Not sure if this is related; apologies if not.
>>> > I have web2py/routes.py containing
>>> >
>>> > """
>>> > routes_in = (
>>> > ('/favicon.ico', '/init/static/favicon.ico'),
>>> > ('/robots.txt', '/init/static/robots.txt'),
>>> > )
>>> > routes_out = ()
>>> > """
>>> >
>>> > and app.yaml containing
>>> >
>>> > """
>>> > - url: /(?P<a>.+?)/static/(?P<b>.+)
>>> > static_files: applications/\1/static/\2
>>> > upload: applications/(.+?)/static/(.+)
>>> > secure: optional
>>> > expiration: "90d"
>>> > """
>>> >
>>> > GAE Launcher at startup is saying:
>>> >
>>> > WARNING 2010-09-15 21:43:18,429 dev_appserver.py:1175] Blocking
>>> > access to static file "/Users/mellis/web2py/applications/init/static/
>>> > favicon.ico"
>>> >
>>> > and thereafter issuing 403's for attempts to get favicon.ico.
>>> >
>>> > What else do I need to do? I'm still using version 184.0.
>>>
>>> I've never used GAE. Aside from the warning and the 403's, does anything
>>> else look wrong? Is the path what you would expect? (It looks like an OS X
>>> path; is that normal for GAE?)
>>>
>>>
>>> >
>>> > Thanks,
>>> > Mike
>>> >
>>> >
>>> > On Sep 15, 9:25 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>>> >> please check trunk in 5 minutes.
>>> >>
>>> >> On Sep 14, 9:56 am, Jonathan Lundell <jlund...@pobox.com> wrote:
>>> >>
>>> >>
>>> >>
>>> >>> Massimo, here's a patch. In rewrite.py, change this:
>>> >>
>>> >>> exec routesfp.read() in symbols
>>> >>
>>> >>> to this:
>>> >>
>>> >>> exec routesfp.read().translate(None, '\r') in symbols
>>> >>
>>> >>> (and test)
>>> >>
>>> >>> I notice that there's something like this elsewhere:
>>> >>
>>> >>> def compile2(code,layer):
>>> >>> """
>>> >>> The +'\n' is necessary else compile fails when code ends in a
>>> comment.
>>> >>> """
>>> >>> return compile(code.rstrip().replace('\r\n','\n')+'\n', layer,
>>> 'exec')
>>> >>
>>> >>> ...though in the case of the rewrite exec call, there doesn't seem to
>>> be a need for a terminal newline, even if I put a comment on the last line.
>>>
>>>
>>>
>>
>>
>>
>
>
>
