solidify python version support

It'd be great to support 3.x, but that's a stretch. Start with 2.7 and work backwards, then work forwards.

Newlines in the Python sections of Simplates are leaked into the output.

^L
^L
<h1>WHAT EXTRA LINES!?</h1>

Yields

\n
\n
<h1>WHAT EXTRA LINES!?</h1>

The \n doesn't literally show up, but I can't get the github flavored markdown to cooperate.

I'm trying to set the response object to something different than what is in the simplate's template page. Aspen's behaviour does not seem to match the documentation.

If I raise a Response, I get the standard error template with the error code:

from aspen import Response
Response.body='content'
raise Response

=> Response is Ok, program!

Trying to create a new response as a response variable does not prevent the template part being run:

response = Response(200,'content')
response

In the docs it's said that the variable named response should be returned as the response object. I tried looking at the simplates code, but could not figure out how the response's namespace is build.

Right now you can do this:

from aspen import Response

def greetings_program(request):
    request.fs = ''
    raise Response(200, "Greetings, program!")

website.hooks.inbound_early.register(greetings_program)

However, this is warty and non-performant (raise vs. return). This would be nicer:

from aspen import Response

def greetings_program(website, request):                                                                                                                            
    return Response(200, "Greetings, program!")

website.handler = greetings_program

aspen's configuration should be in a python file instead INI-style. This will allow for more flexible configuration, including allowing hooks to be configured from the same file.

Want to explicitly import objects from aspen.context into simplates instead of placing them there magically.

*.less should be compiled and served as http://lesscss.org/

I should be able to configure aspen to use different kinds of templates: pystache, cheetah, Jinja, Genshi, etc.

If you set "response" in a simplate content page Aspen will try to use that object to fulfill the request. But if you're doing web service calls inside your simplate and "response" is actually an instance of a class from some HTTP client library (like urllib or requests) then Aspen will break trying to use that to finish with the request, and the error message won't be informative.

Either silently ignore response's that aren't instances of aspen.Response, or fail in that case (or make that configurable).

Docs barely kept up with request and config refactors in 0.15 and 0.16. Collect problems here and preen the docs before 1.0.

Don't have steps to repro but I saw it. Try restarting while in pdb

Looks like there's a bug in check trailing slash.

Hi.

When testing the merged implementation of Jinja2 renderer I stumpled onto a bug.

If there is an template error (unknown tag for instance) inside inherited template and the template contains non-ASCII content, rendering the error message fails with following:

Traceback (most recent call last):
File "/aspen/_cherrypy/wsgiserver.py", line 1246, in communicate
req.respond()
File "/aspen/_cherrypy/wsgiserver.py", line 776, in respond
self.server.gateway(self).respond()
File "/aspen/_cherrypy/wsgiserver.py", line 2028, in respond
response = self.req.server.wsgi_app(self.env, self.start_response)
File "/aspen/website.py", line 31, in call
response = self.handle(request)
File "/aspen/website.py", line 73, in handle
response = self.handle_error_nicely(request)
File "/aspen/website.py", line 118, in handle_error_nicely
aspen.log_dammit(tbs)
File "/aspen/init.py", line 50, in log_dammit
log(message, level=1)
File "/aspen/init.py", line 37, in log
message = unicode(message).encode('UTF-8', 'backslashreplace') # XXX buggy?
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1760: ordinal not in range(128)

If the same error is in the simplate, displaying it is handled correctly. The above error actually escapes usual error display and returns straight to browser. There is no log message in the console.

This bug is in my fork's version of the renderer also. I tested for template errors and UTF-8, but apparently forget to put non-ASCII content in the inherited templates at the same time with an erroneous tag.

I don't see a way to attach my test case, but I can push it to my Aspen fork, if need be. Hm, I notice that you have test cases for renderers (tests/test_rendering.py). I'll try to make some Jinja2 tests.

Jussi

subj. it's in the git repo now, but not in the package

Currently there is computation done on startup based on configuration that is not re-done when configuration values change. For example, if website.logging_threshold is 1 and I set it to 2 programmatically in a simplate, it doesn't propagate through to aspen.LOGGING_THRESHOLD and therefore the change has no effect. It should.

Hi.

I noticed that GET and POST keys and values are byte strings, not Unicode objects. This happens with Aspen version is 0.9.39, Python 2.7, OS X 10.6. Actually, same goes for headers also, but I'm not sure if HTTP allows non-ASCII content in headers.

I made the request in UTF-8 according to Firebug.

Thanks,
Jussi

For some reason, this hook is running at inbound_early. I think I counted enough pages such that it should be running one of the response hooks.

^L
# inbound_early

^L
# inbound_late

^L
# outbound_early

^L
# outbound_late
ws:strip

TB

Traceback (most recent call last):
  File "/home/christian/src/foobar/env/lib/python2.6/site-packages/aspen/website.py", line 46, in handle
    request = self.hooks.run('inbound_early', request)
  File "/home/christian/src/foobar/env/lib/python2.6/site-packages/aspen/configuration/hooks.py", line 27, in run
    thing = hook(thing) or thing
  File "/home/christian/src/foobar/ws.py", line 5, in strip
    response.body = response.body.strip()
AttributeError: 'WwwForm' object has no attribute 'strip'

See https://aspen.ci.cloudbees.com/job/aspen/76/testReport/junit/(root)/test_sockets_socket/test_socket_can_echo/

I noticed this after I pushed some unit tests that didn't touch that code... and verified that it works sometimes by telling jenkins to build it again immediately with no changes made.... at which point it passed.

It's confusing to mix arguments and options. I myself have beat my head against a wall wondering why aspen --root=www/ doesn't work. Just make them all options.

Hi.

I get this error when trying to use aspen with changes_kill arg:

 Starting cherrypy engine.
 Greetings, program! Welcome to port 8080.
 Aspen will die when files change.
 Traceback (most recent call last):
   File "lib/python2.7/site-packages/aspen-0.16.7-py2.7.egg/aspen/server.py", line 55, in main
     restarter.install(website)
   File "lib/python2.7/site-packages/aspen-0.16.7-py2.7.egg/aspen/restarter.py", line 70, in install
     if website.dotaspen is not None:
 AttributeError: 'Website' object has no attribute 'dotaspen'
 Shutting down Aspen website.

I used this Aspen package on Ubuntu 11.10:
http://pypi.python.org/packages/source/a/aspen/aspen-0.16.7.tar.bz2

Thank you.

..what does this mean?

Tip of the iceberg.

Sketch: http://sync.in/aspen-1-0-doc-reorg

OS X Application firewall can't understand Aspen's web server and always asks wether to allow or deny connections to it. In development with constant reloads it is a bit of a pain.

OS X 10.6.7
Stock python 2.6.1
stock setuptools 0.6c9
homebrew installed virtualenv 1.5.2
XCode 4 (so I got bitten by this: http://bugs.python.org/issue11623)

Aspen installed from https://github.com/whit537/aspen/zipball/0.9.15

I followed the quick start document and could reproduce the problem there.

Process *.coffee as http://coffeescript.org/ before serving

The CI at Cloudbees is showing that jython support is broken.

This is to track why.

The main current blocker (causing over 150 errors/failures) is Jython bug http://bugs.jython.org/issue1153

Other failures:

• test_parse_network_address_unix_socket fails due to lack of socket.AF_UNIX
• test_hooks_is_instantiable_with_one_section fails with a NotImplementedError
• test_ConfigurationError_raised_if_no_cwd raises the wrong Error type
• some test_tornado_caches_by_default_after_make_renderer cases fail with an AssertionError
• test_querystring_starts_full fails due to something being unicode that should be a string.

The thrash script is a hack. Now that magicbus is standalone we should use that.

https://bitbucket.org/cherrypy/magicbus/

Right now 'tornado' is the hard-wired default renderer. Default renderers should be configurable per-media type and globally.

All problems with --address values raise the same "Bad address" error. It'd be nice to be more detailed.

Consider using https://github.com/jparise/python-reloader instead of the thrash/kill hack

I have this idea that any time you use os.path.isfile you introduce a race condition and a potential security vulnerability.

• You run isfile and it is True.
• I delete the file before you open it and ... ? What?
• It fails to open.

Hrm. Or ...

• You run isfile and it is False
• I create a file and you have some convoluted logic that depended on there being no file there.
• I trick you into opening a file? Did I place bytes there?

Hrm.

3.3. Path Component

The path component contains data, specific to the authority (or the scheme if there is no authority component), identifying the resource within the scope of that scheme and authority.

  path          = [ abs_path | opaque_part ]

  path_segments = segment *( "/" segment )
  segment       = *pchar *( ";" param )
  param         = *pchar

  pchar         = unreserved | escaped |
                  ":" | "@" | "&" | "=" | "+" | "$" | ","

The path may consist of a sequence of path segments separated by a single slash "/" character. Within a path segment, the characters "/", ";", "=", and "?" are reserved. Each path segment may include a sequence of parameters, indicated by the semicolon ";" character. The parameters are not significant to the parsing of relative references.

http://tools.ietf.org/html/rfc2396.html

Currently Aspen loads configuration from a predetermined list of files:

• /etc/aspen/aspen.conf
• /usr/local/etc/aspen/aspen.conf
• ~/aspen/aspen.conf
• ./.aspen/aspen.conf

This system has the following drawbacks:

• It's not clear where configuration is coming from.
• It's not possible to use a configuration file other than those above.

I'd like instead to support a --conf command line option that points to a file which is exec'd as Python syntax, probably with a website object in its namespace. If multiple --conf options are specified they should be exec'd in the order given on the command line.

For the case where you want to actually send a ^L across the wire.

Got complaints about "channel." Look at nomenclature used in SocketIO, but also look at SockJS.

If you raise Response(404) from a JSON simplate you get mis-labeled HTML content. Could change the content-type though javascript clients won't expect that. Probably better to return an empty object or an object like {"HTTP-error": "Not found"}.

The simplates engine opens all static files in text mode on windows. This means that binary content (such as jpegs and pngs) don't render properly. The following patch (against 0.10.14) forces binary mode, to match the Unix behavior while running on Windows.

PS C:\Users\jaraco\projects\public\aspen> hg diff
diff -r e112d0e654f7 aspen/simplates.py
--- a/aspen/simplates.py Wed Jun 22 00:16:09 2011 -0400
+++ b/aspen/simplates.py Tue Jul 05 19:17:38 2011 -0400
@@ -97,16 +97,17 @@

 """

- simplate = open(request.fs).read()

• mode = 'rb' # open in binary to support binary formats on Windows
• simplate = open(request.fs, mode).read()

We work with simplates exclusively as a bytestring. Any unicode objects

passed in by the user as {{ expressions }} will be encoded with UTF-8 by

# Tornado.

mimetype = mimetypes.guess_type(request.fs, strict=False)[0]
if mimetype is None:

mimetype = request.default_mimetype

Try to exit early.

==================

If the Request-URI is an asterisk (""), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2

aspen.configuration.exceptions.ConfigurationError: Bad address localhost:8044

/foo.html should first be served by ./foo.html, then by a text/html page in ./foo.

I believe this to be more what people think in terms of.

Currently aspen runs files of unknown filetype through the simplates machinery, serving them as text/plain. We should probably just go back to spec and serve them as application/octet-stream. Any filetypes we want to serve as text/plain would then be handled explicitly with a mimetypes.add_type call. At the very least we should shortcut and serve them statically.

Hi.

I hit a snag with UTF-8 content. When a simplate tries to use a variable from first or second page containing non-ASCII characters, simplate will fail in the template processing.

Sample code follows:

"empty first page"
^L
text = u'ääkkönen'
^L
{{ text }}

And this is the error I got:

Traceback (most recent call last):
  File "/Users/jussiarpalahti/py27/lib/python2.7/site-packages/aspen/website.py", line 49, in handle
    response = simplates.handle(request)
  File "/Users/jussiarpalahti/py27/lib/python2.7/site-packages/aspen/simplates.py", line 237, in handle
    response.body = template.generate(**namespace).encode(ENCODING)
  File "/Users/jussiarpalahti/py27/lib/python2.7/site-packages/aspen/_tornado/template.py", line 128, in generate
    return execute()
  File "/Users/jussiarpalahti/testing/blag/index.html", line 9, in _execute
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 31: ordinal not in range(128)

If I put non-ASCII characters in the template page, it works as it should. I tested a tornado template directly and it handles UTF-8 correctly. Even if I read the variable contents from a file it will fail trying to convert it to ASCII. I still haven't got my head aorund the simplates code, so I can't begin to guess where the problem might come.