Categories: IT, Architecture, Linnaeus Award, Python, Cation, CherryPy, Dejavu, WHELPS, WSGI, Robotics and Engineering

Pages: << 1 ... 7 8 9 10 11 12 13 14 15 16 17 >>


Permalink 03:00:51 pm, by fumanchu Email , 292 words   English (US)
Categories: IT

I don't get PUT versus POST

Once in a while, I'll run across posts like Benjamin Carlyle's on REST topics, where the author advocates minimal use of POST, instead preferring PUT for almost every request that has an enclosed entity.

Hogwash. That works fine for blogs and forums, but for real CRUD apps, POST is perfectly fine for updating a resource:

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

In other words, a URI handles a POSTed entity, but is or becomes a PUT entity. When I make a CRUD app, most of my URI's are "entities that accept annotations". It is a very rare operation for me to replace entire entities.

Or perhaps, I'm just thick. Maybe, Fielding is asking me to expose each attribute of, say, an Invoice resource as its own subordinate resource, with its own URI? But that way lies madness, IMO.

So, stealing the layout from Dave Megginson:

Create PUT
Retrieve GET
Update POST


Permalink 09:25:02 am, by fumanchu Email , 10 words   English (US)
Categories: IT

300 *quality* fonts


Permalink 12:58:31 am, by fumanchu Email , 31 words   English (US)
Categories: IT, General

Them talking pictures is gonna sink Hollywood

After a bit of frustration, I finally got Adobe Premiere to capture the live view of my own desktop:

screen capture of a screen capture of a...

Now I can get those clips assembled for Dave's sermon on Sunday. :)


Permalink 11:07:46 pm, by fumanchu Email , 127 words   English (US)
Categories: Python, CherryPy, WSGI

CherryPy WSGI is up and running

Update: 1) "lydon" is Oliver Graf. Thanks, Oliver! 2) the tests all pass now.

"lydon" contributed a recipe for using FastCGI with CherryPy's new WSGI interface. Thanks! (I notice he or she also used my brand new recipe for the Virtual Path Filter—nice to know when someone likes your little side projects. ;)

Peter Hunt has contributed a very nice WSGI server, as well. See the latest SVN trunk for the current version (here's a link to the Timeline.) There's still a bug in the WSGI server; the test suite isn't completing, because the server isn't shutting down when it should. I'm trying to track that down and fix it tonight.


Permalink 11:28:04 am, by fumanchu Email , 41 words   English (US)
Categories: IT

Microsoft Office to use XML by default

via Sam Ruby

The really cool thing this would allow would be the ability to use standard diff tools (subversion, anyone?) on Word, Excel, and Powerpoint documents. This will make our PR staff very happy. :)


Permalink 03:31:02 pm, by fumanchu Email , 542 words   English (US)
Categories: Python, WSGI

WSGI gateway for ASP (Microsoft IIS)

Update: I forgot to address buffering.

As I mentioned, I threw together an WSGI wrapper (gateway) for ASP. Here it is. Feedback welcome.

It blanks out SCRIPT_NAME to behave more like Apache. It also handles URL-rewriting, since that's pretty much the only sane way to use ASP with WSGI (or any framework, for that matter).

WSGI wrapper for ASP.

Example Global.asa for a CherryPy app called "mcontrol":

<script language=Python runat=Server> 
def Application_OnStart():
    Application.Contents("multiprocess") = False
    Application.Contents("multithread") = True
    from mcontrol import chpy

Example handler.asp:

from wsgiref.asp_gateway import handler
from cherrypy.wsgiapp import wsgiApp

handler(Application, Request, Response).run(wsgiApp)


import sys
from wsgiref.handlers import BaseCGIHandler

class ASPInputWrapper(object):
    def __init__(self, Request): = Request.BinaryRead
        size = Request.ServerVariables('CONTENT_LENGTH')
        self.remainder = self.size = int(size)
    def read(self, size=-1):
        if size lt; 0:
            size = self.remainder
        content, size =
        self.remainder -= size
        return content
    def readline(self):
        output = []
        while True:
            # Use an internal buffer instead? Still have to check for \n
            char =
            if not char:
            if char in ('\n', '\r'):
        return ''.join(output)
    def readlines(self, hint=-1):
        lines = []
        while True:
            line = self.readline()
            if not line:
        return lines
    def __iter__(self):
        line = self.readline()
        while line:
            yield line
            # Notice this won't prefetch the next line; it only
            # gets called if the generator is resumed.
            line = self.readline()

class handler(BaseCGIHandler):
    def __init__(self, Application, Request, Response, buffering=True):
        # If you set buffering to False, you must not "Enable Buffering" in
        # the current Virtual Directory, NOR in any of its parent containers
        # (directory, site, or server). IIS 5 and 6 buffer by default.
        # See;en-us;Q306805
        # and
        Response.Buffer = buffering
        env = {}
        for name in Request.ServerVariables:
                # names and values are both probably unicode. coerce them.
                env[str(name)] = str(Request.ServerVariables(name))
            except UnicodeEncodeError, x:
                # There's a potential problem lurking here, since some ASP
                # server var's which are required by WSGI may be high ASCII.
                x.args += ((u"Server Variable '%s'" % name),)
                raise x
        multiprocess = str(Application.Contents("multiprocess"))
        multithread = str(Application.Contents("multithread"))
        # You will probably need *some* form of rewriter to use ASP
        # with WSGI, since ASP requires one physical .asp file
        # per requestable-URL; so far, we support one:
        # Handle URL rewriting done by ISAPI_Rewrite Lite.
        # Note that PATH_TRANSLATED is also rewritten, but we
        # don't make any provision for unmunging that.
        old_path = env.get("HTTP_X_REWRITE_URL", None)
        if old_path:
            # Tear off any params.
            env["PATH_INFO"] = old_path.split("?")[0]
        # ASP puts the same values in SCRIPT_NAME and PATH_INFO,
        # for some odd reason. Empty one of them.
        env["SCRIPT_NAME"] = ""
        self.Response = Response
        self._write = Response.Write
    def _flush(self):
    def send_headers(self):
        self.headers_sent = True
        for key, val in self.headers.items():
            self.Response.AddHeader(key, val)


Permalink 12:02:07 pm, by fumanchu Email , 191 words   English (US)
Categories: Python, CherryPy, WSGI

CherryPy going WSGI...conservatively

As I announced, I've got a new core with both a wsgiapp and the original native httpserver. They both pass all tests.

[Remi] I don't have any problem with WSGI being the preferred interface. But in that case, we need to package with CherryPy a standalone WSGI HTTP server so that people can still run their sites without any external dependencies if they want to (and the server should support thread-pooling).

I'm about to write a WSGI server for CP, so that we can run the test suite against the wsgi handler without any dependency on wsgiref. I can either:

  1. Write a new WSGI server specifically for CherryPy, or
  2. Rewrite the existing native httpserver to have a WSGI interface.

If I did (2), then CP would no longer have a non-WSGI server. I think I'll avoid that for now--it would be better to grow the new interface, test it thoroughly through at least a minor version or two, and cut the old one later if we find nobody is using it.

I should have a patch ready by Monday. :)

Permalink 10:08:40 am, by fumanchu Email , 23 words   English (US)
Categories: IT

Huffington hotlink hullabaloo

From The Huffington Post

Huffington hotlinking and getting caught by, personally

Teh funny. Here's's notice.


Permalink 02:23:49 pm, by fumanchu Email , 117 words   English (US)
Categories: Python, CherryPy, WSGI

Abstracting the CherryPy webserver

CherryPy had a great IRC meeting today. I had several issues I wanted to discuss going into it—not only were they discussed, but I didn't even have to bring them up! :)

One important outcome was: I'm not the only one who wants the included HTTPServer to be less-strongly coupled to the rest of the framework. So I'll be working on that during the rest of the week; I told everyone I'd have a draft ready by Monday. I'll be asking lots of questions on cherrpy-devel, I'm sure. ;)

My biggest hope is that I can now eliminate the "write callable" hack which I just placed in the new wsgiapp module.

<< 1 ... 7 8 9 10 11 12 13 14 15 16 17 >>

August 2019
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31


The requested Blog doesn't exist any more!

XML Feeds

free blog software