On Wed, Aug 6, 2008 at 12:46 PM, David Bolen <[EMAIL PROTECTED]> wrote: > "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). >
Very helpful again. Thanks. >> 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. As I said, this is a nice-to-have, so I am not too worried about it. Thanks, Govind. _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
