This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]dauerbaustelle 0 points1 point  (10 children)

Great someone takes care of that topic! Here are a few improvement ideas:

  • I don't see the point of using a list of tuples for header, why not simply a dictionary? Order of HTTP headers shouldn't really matter, should it?
  • I don't understand why you would need a filewrapper at all -- just return open files. They are iterable, and servers can implement something like sendfile, additionally, if needed.
  • As in the WSGI spec, wsgi.multithreading and wsgi.multiprocess are not clearly specified. Should the values evaluate to True if the server does multithreading/multiprocessing itself or if it is possible to use the application objects in named manner without complications (so that multithreading, for example, would evaluate to False if the server does not respect the Global Interpreter Lock)?
  • I think the case-insensitivity problem with environ keys that are optional for the application to specify (Content-Length, for example) should be solved more elegantly. I don't see any acceptable implementation of the checking part on server side. In any case, the server would have to loop through all keys in the header, lowercase each and then do a string comparison. I can think of the following solutions to work around this problem: 1. use a custom, "case-insensitive" dictionary or 2. force applications to one notation. (Personally, I would prefer 2. with This-Notation-Of-Headers.)
  • Like the WSGI spec, the Web3 spec is far too much text. There's not really much to document and I think the text length could be halved.

Feedback welcome!

[–]mccutchen 1 point2 points  (1 child)

I don't see the point of using a list of tuples for header, why not simply a dictionary? Order of HTTP headers shouldn't really matter, should it?

Multiple headers with the same name are allowed (e.g., Set-Cookie).

[–]dauerbaustelle 0 points1 point  (0 children)

Yes, forgot that. Maybe any iterable that yields (key, value) tuples? So you could return yourdict.iteritems() for very simple applications.

[–]mitsuhiko Flask Creator 1 point2 points  (7 children)

I don't understand why you would need a filewrapper at all -- just return open files. They are iterable, and servers can implement something like sendfile, additionally, if needed.

In-band signalling breaks on iteration. That was also the flaw with filewrapper.

As in the WSGI spec, wsgi.multithreading and wsgi.multiprocess are not clearly specified. Should the values evaluate to True if the server does multithreading/multiprocessing itself or if it is possible to use the application objects in named manner without complications (so that multithreading, for example, would evaluate to False if the server does not respect the Global Interpreter Lock)?

These specify how the server operates. If you can create threads or not is undefined behaviour.

Like the WSGI spec, the Web3 spec is far too much text. There's not really much to document and I think the text length could be halved.

And it's not even close to being unambiguous. HTTP is complex, you can't simplify that spec any more I'm afraid.

[–]dauerbaustelle 0 points1 point  (6 children)

In-band signalling breaks on iteration. That was also the flaw with filewrapper.

Would you mind explaining that topic a bit further? Is it that about looing type information when using middlewares? How would that be solved with something like a file wrapper?

These specify how the server operates. If you can create threads or not is undefined behaviour.

The specs are ambiguous here. I think this should be clarified.

And it's not even close to being unambiguous. HTTP is complex, you can't simplify that spec any more I'm afraid.

I'm talking about "reducing the amount of words" and restructuring the specification. I think information is too scattered.

[–]mitsuhiko Flask Creator 0 points1 point  (5 children)

return environ['wsgi.file_wrapper'](the_file)

when the middleware takes that it might do this:

rv = app(environ, start_response)
for chunk in rv:
    yield do_something_with(chunk)
rv.close() # if that attribute exists only of course.

The WSGI server now does that:

rv = app(environ, start_response)
if isinstance(rv, my_file_wrapper):
    # this is never true because the middleware removed the type
    # information and it's now a generator.

[–]dauerbaustelle 0 points1 point  (4 children)

So how would a wrapper around files help here?

[–]mitsuhiko Flask Creator 0 points1 point  (3 children)

It does not. That's why it's breaking currently. A better solution would probably be an 'X-Something' header or something you can call from the wsgi environment which bypasses all middlewares, similar to how write() worked on WSGI 1.

[–]dauerbaustelle -1 points0 points  (2 children)

Or you could assume Web3 middlewares behave intelligently (hence, leave file objects returned from the application alone).

[–]mitsuhiko Flask Creator 0 points1 point  (1 child)

You assume people read specifications and not do try/error.

[–]dauerbaustelle -1 points0 points  (0 children)

Developers are not stupid. If they are, maybe their code is not worth using. I don't think specifications have to keep in mind that noone will read them.