Jython Journeys » web technology

Transforming with XSLT on Google AppEngine and jython.

alan.kennedy — Tue, 01 Dec 2009 18:42:26 +0000

I’m writing this post in response to a challenge. I wrote a post entitled Jython on Google AppEngine: Why bother?, which was a reply to a statement made by a Google engineer about not seeing the point of running jython on AppEngine. And a similar statement was repeated in a comment on that blog post (i.e. “the gist of what I intended to say was that while it was possible to run Jython on App Engine, I couldn’t think why you’d want to.”)

So rather than get into a back-and-forth of yes-it-is-no-it-isnt-yes-it-is, I thought I’d reply with some simple code that demonstrates something that cannot (currently) be done in cpython on AppEngine, but is easy with jython on AppEngine: XSLT transforms.

So, without further ado, here is the jython source code for running an XSLT transform on Google AppEngine. It is implemented as a jython WSGI application, using xhaus.com’s modjy WSGI gateway for java servlets that was contributed to the jython project a few months back.

In order to get this code running, I suggest you download the modjy on google appengine demo from our downloads site. In that download, there is a jython file called “demo_app.py”. Simply replace the entire contents of that file with the code below, and you’re good to go. If you need help with getting the modjy demo application working on Google AppEngine, see the documentation on the modjy wiki: Running jython WSGI applications on Google AppEngine, with modjy.

__doc__ = """
A demonstration of how to run XSLT transforms on Google AppEngine with jython (not cpython).
Please feel free to use this code in whatever way you wish.
"""
from java.io import StringReader, StringWriter
from javax.xml.transform import Transformer, TransformerFactory
from javax.xml.transform.stream import StreamResult, StreamSource
 
xml_data = """

  
    2001 - A Space Odyssey
    Arthur C Clarke
  
  
    I, Robot
    Isaac Asimov
  
  
    Kil'n people
    David Brin
  

"""
 
xslt_source = """

 


  A list of books, transformed into html from xml using xslt and jython.
  
    
      
      A list of books, transformed into html from xml using xslt and jython.
      Title Author
    
    
    
  


 

"""
 
def generate_html(xml_data, xslt_source):
  transformer = TransformerFactory.newInstance().newTransformer(StreamSource(StringReader(xslt_source)))
  output_buffer = StringWriter()
  transformer.transform(StreamSource(StringReader(xml_data)), StreamResult(output_buffer))
  return output_buffer.buffer.toString()
 
def handler(environ, start_response):
  result = generate_html(xml_data, xslt_source)
  start_response("200 Hoopy", [ ('content-type', 'text/html') ])
  return [result]

Happy Transforming!

Jython on Google AppEngine: Why bother?

alan.kennedy — Mon, 30 Nov 2009 14:40:09 +0000

Why on earth would you want to run jython applications on Google Appengine?

First off, I must apologise for the flippant nature of the attention grabbing title. I’m a jython committer, and a jython user, so I believe that there are very good reasons for running jython on Google AppEngine. (You can read how to do so on the modjy wiki: how to run jython applications on Google AppEngine).

The title is essentially a paraphrase of a statement made by a Google AppEngine Evangelist, at a talk about AppEngine that I attended here in Dublin. The speaker was of the opinion that there was no valid reason for running jython on AppEngine, a statement which I couldn’t let pass.

I think that the core of his reasoning for making that statement was a simple misunderstanding, but a misunderstanding that is common among users who are familiar with python, or users of cpython, but who are not familiar with jython’s use as a JVM scripting language. The misunderstanding is that the only reason for running jython is so that one can run python applications on the JVM, using python’s wealth of "batteries included" APIs. If that is the case, then why bother running jython, when one can simply use the cpython support on AppEngine directly?

To explain, when writing a cpython application that processes email, for example, one can make use of the python’s email module, which provides a wealth of features for dealing with the many complexities of parsing, processing and generating email messages, MIME, etc. Users of jython can also use the python email modules, since those modules are written in pure python. But since jython runs on the Java Virtual Machine(JVM) and permits seamless integration of java and python code, jython users writing email processing also have the option of using the excellent JavaMail APIs, which are just as robust as the pure python modules, and arguably more efficient. So jython users have the best of both worlds: they can use either python APIs or java APIs, with equal ease.

Processing email is perhaps too straightforward an example, in that both python and java have excellent email processing support. But due to the more widespread use of java in the development community in general, java generally has far more support for any given technology need, since there are often multiple options available. A good example of this is cryptography: there is a wealth of java cryptography libraries available, including the excellent Bouncy Castle, Cryptix, Flexiprovider, etc. The choice of crypto libraries in python is generally narrower, supports less functionality, and is sometimes abandon-ware.

So if one’s understanding of jython is simply that it is a way to run pure python modules on the JVM, then the above mentioned mis-understanding is forgivable. But it is simply not the case that the primary usage of jython is to run pure python modules: Jython excels as a dynamic/scripting language for the JVM, and permits the use of java APIs, without having to write java code.

In discussion with the Google engineer after the talk, he conceded that there was one possible use case for running jython on AppEngine, namely that of prototyping java applications. In this scenario, applications would

Be developed in jython, taking advantage of the enormous productivity increases gained by developing in python
Be translated to java once the functionality of the application is complete

My reply to this is: “Why bother with step 2″?

If you’ve got a running application that is fully functional and written in jython, then you don’t need to translate it to java. You should only consider translating it, or parts of it, into java if you really have to. For example, after profiling your jython application, you may find one or two core pieces that are performance bottlenecks: these are prime candidates for translation to java, to improve performance. But there’s no reason to translate the rest of the application: maintainability and productivity is best served by simply leaving the jython code exactly as is.

I suppose a part of the reason why this mis-perception of jython has come about is because python is such an excellent language that it is in the unique position of having two completely independent implementations of the language that run on Google AppEngine. But just because both cpython and jython run on AppEngine doesn’t mean that their usages should be identical. Jython’s place in the AppEngine ecosystem is primarily as a JVM dynamic language.

So, in summary, jython is more than just a mechanism for running pure python code on the JVM: it is an excellent JVM development platform in it’s own right.

I hope I’ve given you some good reasons to consider developing your next Google AppEngine project on jython.

A list of open source HTTP proxies written in Java.

alan.kennedy — Thu, 02 Jul 2009 15:48:51 +0000

A few years ago, as an aide to python web programers, I compiled a database of open source HTTP proxies written in python, which became surprisingly popular.

So I’ve decided to expand the database to encompass the other language that I regularly use, java, and publish a database of open source HTTP proxies written in java.

While carrying out a web development project a few years ago, I needed a HTTP proxy to help with development and debugging. Rather than write my own, I decided to research what open source options were already available.

However, Python is such an easy language to write web servers and proxies in that a lot people had written and puiblished HTTP proxies, so making the decision wasn’t easy. It required a lot of research, which basically meant a code and architectural review of all of the open source python proxies available.

Since most web programmers use a HTTP proxy at some stage, I thought it would be a useful exercise to compile a complete list of the available options, with a comparison table to enable a feature by feature comparison.

The result of that was this comparison table of open source HTTP proxies written in python, which became quite popular, because it saved python programmers going through the same complex comparison and review process I had undertaken.

Since I’m currently working on another proxy-related project, I needed to review available open source HTTP proxies written in java. And I thought I’d save someone some research time by publishing a similar comparison table of open source HTTP proxies in java.

I hope you find it useful.

How to run jython WSGI applications on Google AppEngine with modjy.

alan.kennedy — Sun, 12 Apr 2009 21:36:01 +0000

As you can see from our last blog post, we were delighted to get jython WSGI applications running on Google AppEngine for java using modjy. We promised in that we’d write a tutorial on how to do do that.

Well we’ve done that: you can read the results on the modjy wiki: How to run jython WSGI applications on Google AppEngine with modjy.

If you successfully upload the mody demo application, you should see results like this: modjy demo application running on AppEngine

We’d be happy to know of any successful reports of jython WSGI applications running on AppEngine: please feel free to leave a comment about it.

Modjy running on Google AppEngine.

alan.kennedy — Sun, 12 Apr 2009 08:25:26 +0000

So, after the announcement by Google that their AppEngine could run other JVM languages, including jython, I had to have a go at getting modjy, our jython WSGI to java servlet bridge, running on it.

It wasn’t a complex job, but did require a number of tweaks to the standard jython deployment. I will write up these instructions and make them available very soon.

You can see the results here: modjy demo application running on Google AppEngine.

Jython runs on Google AppEngine!

alan.kennedy — Wed, 08 Apr 2009 13:05:40 +0000

It is now possible to run Jython on Google AppEngine!

If you’re not yet aware of it, Google AppEngine is one of the foremost Cloud Computing offerings currently available. It is also arguably one of the purest options available, since it truly removes the need for the application administrator to consider physical resources (apart from paying for them that is!). The Google AppEngine cloud will automatically scale up the resources as and when required.

This is in contrast to the Amazon EC2 offering, where the application architect has to specially design the application to distribute over the Amazon cloud, including allocating and de-allocating machine instances dynamically.

Yesterday, Google annnounced that they are providing Java on their AppEngine!

And because they’re supporting java, they also get automatic support for other languages that run on the JVM, with jython 2.2 and jython 2.5 being explicitly supported on AppEngine!

This is fantastic news!

The jython team are currently ramping up for a jython 2.5 Release Candidate, which should appear very soon. It’s very likely that we’ll get the Google patches included in jython 2.5 before then.

Discussions are ongoing how about applying the patch, and the issue of contributor agreements.

Watch this space!

Announce: jyson, a pure java JSON codec for jython.

alan.kennedy — Tue, 17 Mar 2009 22:19:15 +0000

I’m delighted to announce the publication of jyson, a fast codec for JavaScript Object Notation (JSON), a lightweight and easy-to-use data interchange format.

As you may know, JSON is used extensively in modern web development, particularly to communicate data between servers and clients in Rich Internet Applications, or Web 2.0 applications. JSON is commonly the preferred choice for data interchange between clients and servers which use a Respresentational State Transfer (REST) based architecture.

JSON is often the preferred choice because it is a fat free alternative to XML. Although we use XML all the time, we fully recognise that it be both complex to work with and inefficient to generate and parse. JSON, on the other hand, is both simple and fast.

Jyson is written in pure java, and should be highly performant. So, if you’re using jython and JSON, we recommend you check out jyson.

Modjy now fully integrated into jython.

alan.kennedy — Sat, 07 Mar 2009 15:40:06 +0000

I’m delighted to announce that modjy, the java servlet to python WSGI gateway that I originally wrote to track the WSGI spec, has now finally been fully integrated into the jython source base.

Modjy has been distributed with jython for several months now, in the form of a third party library, as a zip file; I used to maintain the modjy source code in a private subversion repo. But now all of the java and jython source code for modjy has been checked into the jython source base. I did the integration work on a dedicated modjy branch. The jython BDFL, Frank Wierzbicki, then kindly exercised his considerable subversion fu to integrate that branch with the jython trunk, from whence the first jython 2.5 release candidate will be cut.

Jython 2.5 is a fantastic achievement, a tribute to Frank and all of the jython developers!

Modjy to be distributed with jython.

alan.kennedy — Fri, 31 Oct 2008 17:00:29 +0000

I’m delighted to announce that, modjy, our jython WSGI gateway for Java Servlets, was checked into the jython source repository today, and will be distributed with jython from today forth.

For those not familiar with it, python (and thus jython) has a Batteries Included philosophy, which generally means that you can use it straight out of the box to do what you need; python and jython come with a huge variety of modules to do everything from all popular network protocols to numeric and maths processing to all kinds of databases to crytography to markup processing.

The jython 2.5 distribution already contains a pure python WSGI server, WSGIRef, written by the principal designer of WSGI, Philip J. Eby. There are also lots of other WSGI servers out there, most of which will run on jython, so jython users are not limited to using modjy.

But modjy is unique in one respect. The great attraction of jython is that it allows the user to script the amazing Java Virtual Machine with python, which makes it much easier to deploy python applications inside the incredible range of servers available for java. Modjy’s unique selling point is that it allows the user to deploy python WSGI applications, such as Django, inside java servlet containers.

There will still be a modjy presence on xhaus.com’s website. We’ll continue to host information about modjy, jython, WSGI and J2EE in general on a new modjy.xhaus.com subdomain. Soon, we’ll be hosting a wiki, and possibly some forums, at that domain.

So, it’s onwards and upwards for jython; we’re delighted to continue contributing to jython, and to open source in general.

HTTP Compression in python and jython

alan.kennedy — Sun, 13 Jan 2002 10:00:46 +0000

Index

Introduction
Can the browser handle GZIPped content?
GZIP vs ZLIB
Content-encoding vs Transfer-encoding
Content-length
Character translation on Windows and OS/2
OutputStream vs. Writer in jython servlets
Some links for related reading
Some sample CGI code
Some sample code for mod_python
Some sample code for jython servlets

Introduction

These are some notes on how to do HTTP compression, i.e. compress content before it is sent to the user. The benefits are

You transmit less bandwidth. If the amount of bandwidth you can serve is limited (i.e. you have fixed allocation of X gig/month), then compressing your content before you send it can dramatically lower your transmitted bandwidth.
Your client receives less bandwidth, meaning that pages load faster for them. This is particularly important for people using modems. (Although some modems already do compression. I have no idea how efficient modem compression is compared to gzip. See the Links section for a link to an article which discusses HTML compression vs. modem compression.)

Some points to remember

Although you save on bandwidth transmitted from your server, it comes at a cost of increased CPU usage on the server.
Compressing images probably isn’t worth it. Specialised image compression formats such as GIF, JPEG, and PNG are optimised for the content they carry, and probably cannot be much improved on. So it’s probably not worth compressing images using these techniques.
The best bandwidth saving will be achieved on textual files, i.e. mime types like , , .

I’m not going to go into the details of the rationale or the mechanisms of compression here, I’m just going to stick to telling you how to do http compression in python. If you want to know about the nuts and bolts of compression and http, I suggest you read

Can the browser handle GZIPped content?

Not all browsers can handle compressed content. Old browsers that support HTTP version 0.9 are unlikely to support compressed content. Compression was optional in version 1.0 of the HTTP spec, so only some HTTP 1.0 clients support it, most notably versions 4.x of Netscape Navigator. Support for compression is compulsory in HTTP 1.1, so all HTTP 1.1 clients should support compression. HTTP 1.1 clients include Internet Explorer 5.0 and up. Although I don’t know if Internet Explorer 4.0 is HTTP 1.1 or 1.0, I’m sure IE 4.0 supports gzip compression.

Fortunately, you don’t have to guess or keep a list of which browsers do or do not support compression, since the browsers themselves will inform you of it in their HTTP request. Browsers that support compression will inform you via the HTTP header Accept-Encoding (Check your browser’s headers here). Possible compression methods, as mentioned in RFC2616, include gzip, compress, deflate, and identity. Note that the last one, identity, means no compression. Note also that I’m only going to cover gzip in this document.

So if a browser supports compression, its HTTP request will include a header similar to one of the following

Accept-Encoding: gzip
Accept-Encoding: gzip, deflate

So you need to get the value of the Accept-Encoding header, and check if it contains gzip. If it does, then you can send gzip-compressed content to that browser. Here is some CGI code that checks the content of the header

import string
import os
 
acceptsGzip = 0
try:
    if string.find(os.environ["HTTP_ACCEPT_ENCODING"], "gzip") != -1:
        acceptsGzip = 1
except:
    pass

And here is some mod_python code that checks the content of the header.

import string
 
def acceptsGzip(req):
    """
        Checks if a browser request indicates that the browser will accept
        gzipped content in reply.
    """
    if req.headers_in.has_key('accept-encoding'):
        encodings = req.headers_in['accept-encoding']
        return (string.find(encodings, "gzip") != -1)
    else:
        return 0

And here is some jython servlet code that checks the content of the header.

import string
 
def acceptsGzip(req):
    """
        Checks if a browser request indicates that the browser will accept
        gzipped content in reply.
    """
    encodings = req.getHeader('accept-encoding')
    if encodings != None:
        return (string.find(encodings, "gzip") != -1)
    else:
        return 0

GZIP vs ZLIB

There are a few compression libraries that come with Python. The one which is used in HTTP compression is GZIP. ZLIB, although it is used by GZIP to do part of its job, should not be needed directly in your code.

When a file is compressed for transmission through http, it must be preceded by some special header bytes and followed by some special trailer bytes. Conveniently enough, the python GZIP module constructs exactly those headers and trailers. The details of what those headers and trailers are can be found in RFC1952.

In order to compress using the GZIP module, you’ll need to use code something like this.

import gzip
 
def compressBuf(buf):
    zbuf = cStringIO.StringIO()
    zfile = gzip.GzipFile(mode = 'wb',  fileobj = zbuf, compresslevel = 9)
    zfile.write(buf)
    zfile.close()
    return zbuf.getvalue()

Note that this code compresses into a buffer held in memory, rather than a disk file. This is done through the use of cStringIO.StringIO().

You can vary the compression level by changing the value of the compresslevel parameter, with compresslevel = 9 giving the best compression but consuming the most CPU cycles, and compresslevel = 1 giving the least compression and also consuming the least CPU.

Content-encoding vs Transfer-encoding

When you’re sending compressed content back to the browser, you have to inform the browser of the compression. This is done by the header Content-Encoding. So you should include a header in your response that looks like this.

Content-Encoding: gzip

You don’t need to read any further in this section. The note below about different methods of declaring encoding is just here for interest and completeness.

Note: There is another possible way to communicate the encoding: the Transfer-Encoding header. According to RFC2616, the difference between the two headers is as follows

Content-Encoding should be used when the encoding is a property of the content. So if you were serving a static file that is always compressed, then this is the header to use.
Transfer-Encoding should be used when the encoding is a property of the message used to transmit the content. So you were sending a static file that is normally uncompressed, and were compressing it just so as to minimise bandwidth during the transmission, then this is the header you should use.

However, RFC2616 is unclear what encoding to use if you are generating dynamic content, which may only be transient in memory and has no lifetime beyond the HTTP request-response pair it was contructed for. In such a situation, an argument could be made for using either Content-Encoding or Transfer-Encoding.

Rather than try to resolve that (potentially unresolvable) issue, I would just like to point out that majority of software "out there" seems to have opted for using Content-Encoding, and that’s the choice that I’ve made as well. You are, of course, free to choose otherwise.

Content-Length

You also need to tell the client browser the length of the compressed content you are sending. This is done by sending a Content-Length header, like this.

Content-Length: xyz

where xyz is the COMPRESSED length of the content.

There seems to be some "folk wisdom" out there on the ‘net that you should send the uncompressed length of the content. This is wrong! RFC2616 is quite clear about this. If you are interested, read sections 7.2.2 Entity-Length and 4.4 Message Length.

As far as I can see, the definitive statement on this matter is at the end of section 4.4 (I have underlined the relevant statement)

When a Content-Length is given in a message where a message-body
is allowed, its field value MUST exactly match the number of OCTETs
in the message-body. HTTP/1.1 user agents MUST notify the user when
an invalid length is received and detected.

Character translation on Windows and OS/2

If you’re working in CGI, and on Windows or on OS/2, you need to be careful about character translation.

As you may be aware, Windows and OS/2 are different from other platforms in the way that they represent an end of line. Whereas most platforms, including *nix, represent line ends as an ASCII linefeed (hex 0×0A, octal 012, python escape string ‘\n’), Windows and OS/2 represent end-of-line as a sequence of two characters, an ASCII carriage return followed by an ASCII linefeed (hex 0×0D 0×0A, octal 015 012, python escape string ‘\r\n’). Therefore, when you print anything in python, or write anything to sys.stdout, using code like this

print "Hello World!"
sys.stdout.write("Hello World!\n")

then both Windows and OS/2 filter the characters, and turn all linefeed characters into a sequence of carriage return followed by linefeed.

This is fine when you’re printing text. But when you’re trying to send binary information, particularly a compressed gzipped file, then this translation will corrupt the binary content, and your transmission of gzip compressed content will fail. Therefore, you have to disable this character translation in order for transmission of gzipped content to work.

When you’re working in CGI, the best way to do this is with the “-u” command line flag to python. This was kindly pointed out by Richie Hindle, who says

…… There is a much simpler way to switch off character translation of the standard
channels. The python interpreter accepts the -u switch to mean “make the
standard channels both unbuffered and binary.” This is tailor-made for
CGI – change your shebang line from “#!…python” to “#!…python -u” and
everything will work without changing your code (and without relying on
platorm-specific modules like msvcrt). Responsiveness may even improve
due to the lack of buffering – and that’s also true on platforms like Unix
which don’t do character translation.

A less convenient method is to execute some platform specific code to disable character translation inside your script. On Windows (MSVC), you should execute some code like this

import msvcrt
import os
import sys
msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY)

I don’t know what the equivalent code is on Windows (CygWin) or OS/2. If anyone does, email it to me, and I’ll include it in this page.

OutputStream vs. Writer in jython servlets.

Under the J2EE Servlet interface, you have a choice of two different ways to output generated content. They are

Through an OutputStream (obtained by calling ServletResponse.getOutputStream()). OutputStreams do not carry out character translation on their output.
Through a Writer (obtained by calling ServletResponse.getWriter()). Writers carry out character translation on their output, i.e. they will change the value of bytes in the content output by the servlet, to ensure that it meets the character encoding requirements of the client.

Since compressed gzip content is a (dense) binary format, none of the output bytes should be translated. If any bytes are translated, the output may be corrupted and the recipient may be unable to decode it. Therefore, you must output compressed content through a (non-translating) OutputStream object.

Some links for related reading

W3C: Compression and Performance

Some sample CGI code

So, without further ado, here is some sample CGI code that will transmit compressed HTML to gzip capable browsers.

#! /path/to/python -u
 
import string
import os
import sys
import gzip
import cStringIO
 
def compressBuf(buf):
    zbuf = cStringIO.StringIO()
    zfile = gzip.GzipFile(mode = 'wb',  fileobj = zbuf, compresslevel = 6)
    zfile.write(buf)
    zfile.close()
    return zbuf.getvalue()
 
def testAcceptsGzip():
    acceptsGzip = 0
    try:
        if string.find(os.environ["HTTP_ACCEPT_ENCODING"], "gzip") != -1:
            acceptsGzip = 1
    except:
        pass
    return acceptsGzip
 
def sendHtml(buf):
    sys.stdout.write("Content-type: text/html\r\n")
    if testAcceptsGzip():
        zbuf = compressBuf(buf)
        sys.stdout.write("Content-Encoding: gzip\r\n")
        sys.stdout.write("Content-Length: %d\r\n" % (len(zbuf)))
        sys.stdout.write("\r\n")
        sys.stdout.write(zbuf)
    else:
        sys.stdout.write("\r\n")
        sys.stdout.write(buf)
 
myHtml = """hello compressed world!
"""
sendHtml(myHtml)

Some sample mod python code

And here is some sample mod python code that will transmit compressed HTML to gzip capable browsers.

import string
import os
import sys
import gzip
import cStringIO
from   mod_python import apache
 
def compressBuf(buf):
    zbuf = cStringIO.StringIO()
    zfile = gzip.GzipFile(mode = 'wb',  fileobj = zbuf, compresslevel = 6)
    zfile.write(buf)
    zfile.close()
    return zbuf.getvalue()
 
def testAcceptsGzip(req):
    if req.headers_in.has_key('accept-encoding'):
        encodings = req.headers_in['accept-encoding']
        return (string.find(encodings, "gzip") != -1)
    else:
        return 0
 
def handler(req):
    req.content_type = "text/html"
    myHtml = """hello compressed world!
"""
    if testAcceptsGzip(req):
        zbuf = compressBuf(myHtml)
        req.headers_out['Content-Encoding'] = 'gzip'
        req.headers_out['Content-Length'] = '%d' % (len(zbuf))
        req.send_http_header()
        req.write(zbuf)
    else:
        req.send_http_header()
        req.write(myHtml)
    return apache.OK

Some sample jython servlet code

And here is some sample jython servlet code that will transmit compressed HTML to gzip capable browsers.

import  javax.servlet.http.HttpServlet
 
import  cStringIO
import  gzip
import  string
 
def compressBuf(buf):
    zbuf = cStringIO.StringIO()
    zfile = gzip.GzipFile(mode = 'wb',  fileobj = zbuf, compresslevel = 6)
    zfile.write(buf)
    zfile.close()
    return zbuf.getvalue()
 
def acceptsGzip(req):
    encodings = req.getHeader('accept-encoding')
    if encodings != None:
        return (string.find(encodings, "gzip") != -1)
    else:
        return 0
 
class compressor(javax.servlet.http.HttpServlet):
 
    def service(self, req, resp):
        resp.setContentType('text/html')
        myHtml = """hello compressed world!
"""
        if acceptsGzip(req):
            binarychan = resp.getOutputStream()
            zbuf = compressBuf(myHtml)
            resp.setHeader('Content-Encoding', 'gzip')
            resp.setHeader('Content-Length', '%d' % len(zbuf))
            binarychan.write(zbuf)
        else:
            textchan = resp.getWriter()
            textchan.write(myHtml)