lukearno/static

A very simple WSGI way to serve static and dynamic content.

static's Issues

Bugs with Content-Type headers?

I'm referencing this from dj-static's issue #25. Specifically there's an issue in production with unicode strings being passed as headers which fails inside wsgiref.

Merge Static3

Fold in the work that has been done in the Static3 fork.

rmohr/static3#2

Tentative steps:

• add travis support
• add any missing features from Static3 to Static
• grow/change the tests as needed
• update READMEs on both projects to reflect the merge
• release

Feature Sugestion: Serve a Default Document on 404

The mechanism for this seems to be in place with the not_found app, but it would require folks to roll their own WSGI application to serve up the file.

Could a WSGI app that serves a single file be added to static? This would probably involve pulling up a lot of the file sending stuff in Cling.__call__ to a base class. I'd envision something like:

import static

static_app = static.Cling('/var/www', not_found=static.SingleFile('/var/www/index.html'))

# run the app

My use case for this is working on a single-page app. If a file isn't found, I want to serve up the index document and let the JS router take over.

Add Travis Support

Right now you can just run the tests against various versions of python using the makefile and this is done before every release. Maybe the simplest thing is to have Travis just run make?

wsgi app in the root folder

Hello
This is certainly a stupid question but I'm stuck here
I simply want to serve the folder (containing an index.html) where resides my wsgi app
it just reads:
import static
application = static.Cling('/')

This throws a 404, and any other path I try (including the absolute path to the hoster web folder) fails
thank you

list directories

For my most time, I don't know the exact path of the file I want. It would be very helpful if I can access a directory.

currently, access directly to a directory will raise 404 error

Default Content-Type should be application/octet-stream

The default fallback Content-Type is currently text/plain. However, is should be application/octet-stream. In fact, RFC 2046 states in section 4.5.1:

The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data.

Additionally, the standard library http.server.SimpleHTTPRequestHandler uses application/octet-stream as the default fallback (as does Tornado and various other third-party static file servers). Interestingly, the standard library http.server.SimpleHTTPRequestHander adds a few custom types defined as text/plain for those few cases were undefined types might actually need to be served as text/plain.

However, in most cases, application/octet-stream is a better fallback. In fact, I have personally encountered the following file types which fail to be properly handled by a browser if not served by either their correct Content-Type or the application/octet-stream fallback.

File Extension	Expected Content-Type	Acceptable Fallback
.woff2	font/woff2	application/octet-stream
.woff	font/woff or application/font-woff	application/octet-stream
.ttf	font/ttf	application/octet-stream
.mustache	text/template	application/octet-stream
.json	application/json	application/octet-stream

In each case, the standard mimetypes library fails to return a proper type on Windows. By default, the mimetypes library uses the types as defined by the OS. Therefore, the results can be different from machine to machine and no given type can be guaranteed to be defined on any given system. While some of the above file types would seem to be common (particularly .json), with the great diversity out there, that assumption should not be made.

For the above reason, the Whitenoise static server library (which also uses application/octet-stream as the default fallback) defines their own Content-Types with the following comment in their code:

We use our own set of default media types rather than the system-supplied
ones. This ensures consistent media type behaviour across varied
environments. The defaults are based on those shipped with nginx, with
some custom additions.

Those custom additions are here. I have to wonder if it would make sense for Static to do the same. Regardless, the default fallback should be application/octet-stream, or at the very least, be easily overridable by the user.

Use with Selector

Is there an example somewhere of integrating this with Selector? If not, could someone put one together pretty please?

Missings README.md on pypi

Hello, looks like you're migrating this project to github, terrific!
The current version that's listed on pypi is missing its README.md file, making pip install fail, I think.

Downloading/unpacking static
  Downloading static-1.0.0.tar.gz
  Running setup.py (path:/home/will/.virtualenvs/thoth/build/static/setup.py) egg_info for package static
    Traceback (most recent call last):
      File "<string>", line 17, in <module>
      File "/home/will/.virtualenvs/thoth/build/static/setup.py", line 7, in <module>
        with open('README.md') as readme_file:
    FileNotFoundError: [Errno 2] No such file or directory: 'README.md'
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):

  File "<string>", line 17, in <module>

  File "/home/will/.virtualenvs/thoth/build/static/setup.py", line 7, in <module>

    with open('README.md') as readme_file:

FileNotFoundError: [Errno 2] No such file or directory: 'README.md'

Unable to kill with ctrl-C on Windows

Hi - I'm unable to kill the "static" process with control-C . I am on Windows running the Git Bash terminal.

Any suggestions would be greatly appreciated!

Add a license file

The code is MIT and that requires a license file to be shipped with the source distribution and binaries but there is no license file in the code base.

Update bitbucket and various links to your personal website

There are still lots of places pointing to your personal website (/project/static) which doesn't exists anymore and to the bitbucket repo which I think has gone stale too.

Problem with relative paths

I used this snipped to create a static serving app:

static.Cling(os.path.dirname(__file__))

But it does not work: the _is_under_root test fails. If I pass an absolute path instead, no problem anymore. I think that, if static.Cling needs an absolute path to work, it should make it itself. Or maybe, there's a bug in the _is_under_root method.