"Govind Salinas" <[EMAIL PROTECTED]> writes: > There are a few things wrong with my current approach. One is that it > feels sort of like a hack the way I am doing it. It doesn't seem like the > right way. Second, since manually doing things that I normally expect > the web server to be doing
Remember, with twisted.web, for the most part aside from pure HTTP processing, not much is going to happen for free without explicitly being coded. There are some utility method (like for request sessions) and some utility modules (like static.py for file serving), but your code is pretty much in charge, for better or worse :-) > the web server to be doing, I expect there are 100 things that I should > be doing that I am not to act like a proper server. For instance, my > css pages wouldn't load so I am manually setting the content-type, > but *only* for css pages. If I end up needing other types of files, I > will have to add that in as well. twisted.web's static.File implementation does the content type based on file extension, using Python's internal mimetypes module dictionary, some custom additions, and anything in /etc/mime.types by default. You can also augment class or instance contentTypes variable if needed to apply your own mappings, as well as establish a default mapping for a file/directory for non-matching files when you instantiate static.File (see the favicon usage in my last post). For resources that aren't static and identifiable by file extension, yes, you'll need to establish the correct content type as part of your resource handler during request processing if it's not going to be HTML. > Another example is that I am having > to roll my own page-not-found implementation. Aside from setting > the response code to 404, I am not sure what else I need to be doing. Depends on what you want the user to see in such a case. I don't think anything more than that is truly required for correct operation protocol wise. The resource is still in control of what will be rendered, so you can use your own template, static content, etc.. in addition to setting the response code. twisted.web.error has some simple resources that render some plain text and set the appropriate HTTP response code, but yes, anything much above that is your responsibility. The only exception to this is if displayTracebacks is set to True (the default) in your Site object. In that case, exceptions/Failures that reach the top level will be rendered nicely to the browser (using twisted.web.util.formatFailure). > This is not too important, I was hoping that there was a "framework" that I > could use that would be portable to other webservers if someone wanted > to do so. Sounds like you may be looking for a more extensive framework, perhaps with a wsgi interface. twisted.web is largely a protocol implementation. -- David _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
