2 :mod:`cgi` --- Common Gateway Interface support.
3 ================================================
6 :synopsis: Helpers for running Python scripts via the Common Gateway Interface.
15 single: Common Gateway Interface
17 Support module for Common Gateway Interface (CGI) scripts.
19 This module defines a number of utilities for use by CGI scripts written in
28 A CGI script is invoked by an HTTP server, usually to process user input
29 submitted through an HTML ``<FORM>`` or ``<ISINDEX>`` element.
31 Most often, CGI scripts live in the server's special :file:`cgi-bin` directory.
32 The HTTP server places all sorts of information about the request (such as the
33 client's hostname, the requested URL, the query string, and lots of other
34 goodies) in the script's shell environment, executes the script, and sends the
35 script's output back to the client.
37 The script's input is connected to the client too, and sometimes the form data
38 is read this way; at other times the form data is passed via the "query string"
39 part of the URL. This module is intended to take care of the different cases
40 and provide a simpler interface to the Python script. It also provides a number
41 of utilities that help in debugging scripts, and the latest addition is support
42 for file uploads from a form (if your browser supports it).
44 The output of a CGI script should consist of two sections, separated by a blank
45 line. The first section contains a number of headers, telling the client what
46 kind of data is following. Python code to generate a minimal header section
49 print "Content-Type: text/html" # HTML is following
50 print # blank line, end of headers
52 The second section is usually HTML, which allows the client software to display
53 nicely formatted text with header, in-line images, etc. Here's Python code that
54 prints a simple piece of HTML::
56 print "<TITLE>CGI script output</TITLE>"
57 print "<H1>This is my first CGI script</H1>"
61 .. _using-the-cgi-module:
66 Begin by writing ``import cgi``. Do not use ``from cgi import *`` --- the
67 module defines all sorts of names for its own use or for backward compatibility
68 that you don't want in your namespace.
70 When you write a new script, consider adding the line::
72 import cgitb; cgitb.enable()
74 This activates a special exception handler that will display detailed reports in
75 the Web browser if any errors occur. If you'd rather not show the guts of your
76 program to users of your script, you can have the reports saved to files
77 instead, with a line like this::
79 import cgitb; cgitb.enable(display=0, logdir="/tmp")
81 It's very helpful to use this feature during script development. The reports
82 produced by :mod:`cgitb` provide information that can save you a lot of time in
83 tracking down bugs. You can always remove the ``cgitb`` line later when you
84 have tested your script and are confident that it works correctly.
86 To get at submitted form data, it's best to use the :class:`FieldStorage` class.
87 The other classes defined in this module are provided mostly for backward
88 compatibility. Instantiate it exactly once, without arguments. This reads the
89 form contents from standard input or the environment (depending on the value of
90 various environment variables set according to the CGI standard). Since it may
91 consume standard input, it should be instantiated only once.
93 The :class:`FieldStorage` instance can be indexed like a Python dictionary, and
94 also supports the standard dictionary methods :meth:`has_key` and :meth:`keys`.
95 The built-in :func:`len` is also supported. Form fields containing empty
96 strings are ignored and do not appear in the dictionary; to keep such values,
97 provide a true value for the optional *keep_blank_values* keyword parameter when
98 creating the :class:`FieldStorage` instance.
100 For instance, the following code (which assumes that the
101 :mailheader:`Content-Type` header and blank line have already been printed)
102 checks that the fields ``name`` and ``addr`` are both set to a non-empty
105 form = cgi.FieldStorage()
106 if not (form.has_key("name") and form.has_key("addr")):
107 print "<H1>Error</H1>"
108 print "Please fill in the name and addr fields."
110 print "<p>name:", form["name"].value
111 print "<p>addr:", form["addr"].value
112 ...further form processing here...
114 Here the fields, accessed through ``form[key]``, are themselves instances of
115 :class:`FieldStorage` (or :class:`MiniFieldStorage`, depending on the form
116 encoding). The :attr:`value` attribute of the instance yields the string value
117 of the field. The :meth:`getvalue` method returns this string value directly;
118 it also accepts an optional second argument as a default to return if the
119 requested key is not present.
121 If the submitted form data contains more than one field with the same name, the
122 object retrieved by ``form[key]`` is not a :class:`FieldStorage` or
123 :class:`MiniFieldStorage` instance but a list of such instances. Similarly, in
124 this situation, ``form.getvalue(key)`` would return a list of strings. If you
125 expect this possibility (when your HTML form contains multiple fields with the
126 same name), use the :func:`getlist` function, which always returns a list of
127 values (so that you do not need to special-case the single item case). For
128 example, this code concatenates any number of username fields, separated by
131 value = form.getlist("username")
132 usernames = ",".join(value)
134 If a field represents an uploaded file, accessing the value via the
135 :attr:`value` attribute or the :func:`getvalue` method reads the entire file in
136 memory as a string. This may not be what you want. You can test for an uploaded
137 file by testing either the :attr:`filename` attribute or the :attr:`file`
138 attribute. You can then read the data at leisure from the :attr:`file`
141 fileitem = form["userfile"]
143 # It's an uploaded file; count lines
146 line = fileitem.file.readline()
148 linecount = linecount + 1
150 If an error is encountered when obtaining the contents of an uploaded file
151 (for example, when the user interrupts the form submission by clicking on
152 a Back or Cancel button) the :attr:`done` attribute of the object for the
153 field will be set to the value -1.
155 The file upload draft standard entertains the possibility of uploading multiple
156 files from one field (using a recursive :mimetype:`multipart/\*` encoding).
157 When this occurs, the item will be a dictionary-like :class:`FieldStorage` item.
158 This can be determined by testing its :attr:`type` attribute, which should be
159 :mimetype:`multipart/form-data` (or perhaps another MIME type matching
160 :mimetype:`multipart/\*`). In this case, it can be iterated over recursively
161 just like the top-level form object.
163 When a form is submitted in the "old" format (as the query string or as a single
164 data part of type :mimetype:`application/x-www-form-urlencoded`), the items will
165 actually be instances of the class :class:`MiniFieldStorage`. In this case, the
166 :attr:`list`, :attr:`file`, and :attr:`filename` attributes are always ``None``.
169 Higher Level Interface
170 ----------------------
172 .. versionadded:: 2.2
174 The previous section explains how to read CGI form data using the
175 :class:`FieldStorage` class. This section describes a higher level interface
176 which was added to this class to allow one to do it in a more readable and
177 intuitive way. The interface doesn't make the techniques described in previous
178 sections obsolete --- they are still useful to process file uploads efficiently,
181 .. XXX: Is this true ?
183 The interface consists of two simple methods. Using the methods you can process
184 form data in a generic way, without the need to worry whether only one or more
185 values were posted under one name.
187 In the previous section, you learned to write following code anytime you
188 expected a user to post more than one value under one name::
190 item = form.getvalue("item")
191 if isinstance(item, list):
192 # The user is requesting more than one item.
194 # The user is requesting only one item.
196 This situation is common for example when a form contains a group of multiple
197 checkboxes with the same name::
199 <input type="checkbox" name="item" value="1" />
200 <input type="checkbox" name="item" value="2" />
202 In most situations, however, there's only one form control with a particular
203 name in a form and then you expect and need only one value associated with this
204 name. So you write a script containing for example this code::
206 user = form.getvalue("user").upper()
208 The problem with the code is that you should never expect that a client will
209 provide valid input to your scripts. For example, if a curious user appends
210 another ``user=foo`` pair to the query string, then the script would crash,
211 because in this situation the ``getvalue("user")`` method call returns a list
212 instead of a string. Calling the :meth:`toupper` method on a list is not valid
213 (since lists do not have a method of this name) and results in an
214 :exc:`AttributeError` exception.
216 Therefore, the appropriate way to read form data values was to always use the
217 code which checks whether the obtained value is a single value or a list of
218 values. That's annoying and leads to less readable scripts.
220 A more convenient approach is to use the methods :meth:`getfirst` and
221 :meth:`getlist` provided by this higher level interface.
224 .. method:: FieldStorage.getfirst(name[, default])
226 This method always returns only one value associated with form field *name*.
227 The method returns only the first value in case that more values were posted
228 under such name. Please note that the order in which the values are received
229 may vary from browser to browser and should not be counted on. [#]_ If no such
230 form field or value exists then the method returns the value specified by the
231 optional parameter *default*. This parameter defaults to ``None`` if not
235 .. method:: FieldStorage.getlist(name)
237 This method always returns a list of values associated with form field *name*.
238 The method returns an empty list if no such form field or value exists for
239 *name*. It returns a list consisting of one item if only one such value exists.
241 Using these methods you can write nice compact code::
244 form = cgi.FieldStorage()
245 user = form.getfirst("user", "").upper() # This way it's safe.
246 for item in form.getlist("item"):
255 These classes, present in earlier versions of the :mod:`cgi` module, are
256 still supported for backward compatibility. New applications should use the
257 :class:`FieldStorage` class.
259 :class:`SvFormContentDict` stores single value form content as dictionary; it
260 assumes each field name occurs in the form only once.
262 :class:`FormContentDict` stores multiple value form content as a dictionary (the
263 form items are lists of values). Useful if your form contains multiple fields
266 Other classes (:class:`FormContent`, :class:`InterpFormContentDict`) are present
267 for backwards compatibility with really old applications only. If you still use
268 these and would be inconvenienced when they disappeared from a next version of
269 this module, drop me a note.
272 .. _functions-in-cgi-module:
277 These are useful if you want more control, or if you want to employ some of the
278 algorithms implemented in this module in other circumstances.
281 .. function:: parse(fp[, keep_blank_values[, strict_parsing]])
283 Parse a query in the environment or from a file (the file defaults to
284 ``sys.stdin``). The *keep_blank_values* and *strict_parsing* parameters are
285 passed to :func:`parse_qs` unchanged.
288 .. function:: parse_qs(qs[, keep_blank_values[, strict_parsing]])
290 Parse a query string given as a string argument (data of type
291 :mimetype:`application/x-www-form-urlencoded`). Data are returned as a
292 dictionary. The dictionary keys are the unique query variable names and the
293 values are lists of values for each name.
295 The optional argument *keep_blank_values* is a flag indicating whether blank
296 values in URL encoded queries should be treated as blank strings. A true value
297 indicates that blanks should be retained as blank strings. The default false
298 value indicates that blank values are to be ignored and treated as if they were
301 The optional argument *strict_parsing* is a flag indicating what to do with
302 parsing errors. If false (the default), errors are silently ignored. If true,
303 errors raise a :exc:`ValueError` exception.
305 Use the :func:`urllib.urlencode` function to convert such dictionaries into
309 .. function:: parse_qsl(qs[, keep_blank_values[, strict_parsing]])
311 Parse a query string given as a string argument (data of type
312 :mimetype:`application/x-www-form-urlencoded`). Data are returned as a list of
315 The optional argument *keep_blank_values* is a flag indicating whether blank
316 values in URL encoded queries should be treated as blank strings. A true value
317 indicates that blanks should be retained as blank strings. The default false
318 value indicates that blank values are to be ignored and treated as if they were
321 The optional argument *strict_parsing* is a flag indicating what to do with
322 parsing errors. If false (the default), errors are silently ignored. If true,
323 errors raise a :exc:`ValueError` exception.
325 Use the :func:`urllib.urlencode` function to convert such lists of pairs into
329 .. function:: parse_multipart(fp, pdict)
331 Parse input of type :mimetype:`multipart/form-data` (for file uploads).
332 Arguments are *fp* for the input file and *pdict* for a dictionary containing
333 other parameters in the :mailheader:`Content-Type` header.
335 Returns a dictionary just like :func:`parse_qs` keys are the field names, each
336 value is a list of values for that field. This is easy to use but not much good
337 if you are expecting megabytes to be uploaded --- in that case, use the
338 :class:`FieldStorage` class instead which is much more flexible.
340 Note that this does not parse nested multipart parts --- use
341 :class:`FieldStorage` for that.
344 .. function:: parse_header(string)
346 Parse a MIME header (such as :mailheader:`Content-Type`) into a main value and a
347 dictionary of parameters.
352 Robust test CGI script, usable as main program. Writes minimal HTTP headers and
353 formats all information provided to the script in HTML form.
356 .. function:: print_environ()
358 Format the shell environment in HTML.
361 .. function:: print_form(form)
363 Format a form in HTML.
366 .. function:: print_directory()
368 Format the current directory in HTML.
371 .. function:: print_environ_usage()
373 Print a list of useful (used by CGI) environment variables in HTML.
376 .. function:: escape(s[, quote])
378 Convert the characters ``'&'``, ``'<'`` and ``'>'`` in string *s* to HTML-safe
379 sequences. Use this if you need to display text that might contain such
380 characters in HTML. If the optional flag *quote* is true, the quotation mark
381 character (``'"'``) is also translated; this helps for inclusion in an HTML
382 attribute value, as in ``<A HREF="...">``. If the value to be quoted might
383 include single- or double-quote characters, or both, consider using the
384 :func:`quoteattr` function in the :mod:`xml.sax.saxutils` module instead.
389 Caring about security
390 ---------------------
392 .. index:: pair: CGI; security
394 There's one important rule: if you invoke an external program (via the
395 :func:`os.system` or :func:`os.popen` functions. or others with similar
396 functionality), make very sure you don't pass arbitrary strings received from
397 the client to the shell. This is a well-known security hole whereby clever
398 hackers anywhere on the Web can exploit a gullible CGI script to invoke
399 arbitrary shell commands. Even parts of the URL or field names cannot be
400 trusted, since the request doesn't have to come from your form!
402 To be on the safe side, if you must pass a string gotten from a form to a shell
403 command, you should make sure the string contains only alphanumeric characters,
404 dashes, underscores, and periods.
407 Installing your CGI script on a Unix system
408 -------------------------------------------
410 Read the documentation for your HTTP server and check with your local system
411 administrator to find the directory where CGI scripts should be installed;
412 usually this is in a directory :file:`cgi-bin` in the server tree.
414 Make sure that your script is readable and executable by "others"; the Unix file
415 mode should be ``0755`` octal (use ``chmod 0755 filename``). Make sure that the
416 first line of the script contains ``#!`` starting in column 1 followed by the
417 pathname of the Python interpreter, for instance::
419 #!/usr/local/bin/python
421 Make sure the Python interpreter exists and is executable by "others".
423 Make sure that any files your script needs to read or write are readable or
424 writable, respectively, by "others" --- their mode should be ``0644`` for
425 readable and ``0666`` for writable. This is because, for security reasons, the
426 HTTP server executes your script as user "nobody", without any special
427 privileges. It can only read (write, execute) files that everybody can read
428 (write, execute). The current directory at execution time is also different (it
429 is usually the server's cgi-bin directory) and the set of environment variables
430 is also different from what you get when you log in. In particular, don't count
431 on the shell's search path for executables (:envvar:`PATH`) or the Python module
432 search path (:envvar:`PYTHONPATH`) to be set to anything interesting.
434 If you need to load modules from a directory which is not on Python's default
435 module search path, you can change the path in your script, before importing
436 other modules. For example::
439 sys.path.insert(0, "/usr/home/joe/lib/python")
440 sys.path.insert(0, "/usr/local/lib/python")
442 (This way, the directory inserted last will be searched first!)
444 Instructions for non-Unix systems will vary; check your HTTP server's
445 documentation (it will usually have a section on CGI scripts).
448 Testing your CGI script
449 -----------------------
451 Unfortunately, a CGI script will generally not run when you try it from the
452 command line, and a script that works perfectly from the command line may fail
453 mysteriously when run from the server. There's one reason why you should still
454 test your script from the command line: if it contains a syntax error, the
455 Python interpreter won't execute it at all, and the HTTP server will most likely
456 send a cryptic error to the client.
458 Assuming your script has no syntax errors, yet it does not work, you have no
459 choice but to read the next section.
462 Debugging CGI scripts
463 ---------------------
465 .. index:: pair: CGI; debugging
467 First of all, check for trivial installation errors --- reading the section
468 above on installing your CGI script carefully can save you a lot of time. If
469 you wonder whether you have understood the installation procedure correctly, try
470 installing a copy of this module file (:file:`cgi.py`) as a CGI script. When
471 invoked as a script, the file will dump its environment and the contents of the
472 form in HTML form. Give it the right mode etc, and send it a request. If it's
473 installed in the standard :file:`cgi-bin` directory, it should be possible to
474 send it a request by entering a URL into your browser of the form::
476 http://yourhostname/cgi-bin/cgi.py?name=Joe+Blow&addr=At+Home
478 If this gives an error of type 404, the server cannot find the script -- perhaps
479 you need to install it in a different directory. If it gives another error,
480 there's an installation problem that you should fix before trying to go any
481 further. If you get a nicely formatted listing of the environment and form
482 content (in this example, the fields should be listed as "addr" with value "At
483 Home" and "name" with value "Joe Blow"), the :file:`cgi.py` script has been
484 installed correctly. If you follow the same procedure for your own script, you
485 should now be able to debug it.
487 The next step could be to call the :mod:`cgi` module's :func:`test` function
488 from your script: replace its main code with the single statement ::
492 This should produce the same results as those gotten from installing the
493 :file:`cgi.py` file itself.
495 When an ordinary Python script raises an unhandled exception (for whatever
496 reason: of a typo in a module name, a file that can't be opened, etc.), the
497 Python interpreter prints a nice traceback and exits. While the Python
498 interpreter will still do this when your CGI script raises an exception, most
499 likely the traceback will end up in one of the HTTP server's log files, or be
500 discarded altogether.
502 Fortunately, once you have managed to get your script to execute *some* code,
503 you can easily send tracebacks to the Web browser using the :mod:`cgitb` module.
504 If you haven't done so already, just add the line::
506 import cgitb; cgitb.enable()
508 to the top of your script. Then try running it again; when a problem occurs,
509 you should see a detailed report that will likely make apparent the cause of the
512 If you suspect that there may be a problem in importing the :mod:`cgitb` module,
513 you can use an even more robust approach (which only uses built-in modules)::
516 sys.stderr = sys.stdout
517 print "Content-Type: text/plain"
521 This relies on the Python interpreter to print the traceback. The content type
522 of the output is set to plain text, which disables all HTML processing. If your
523 script works, the raw HTML will be displayed by your client. If it raises an
524 exception, most likely after the first two lines have been printed, a traceback
525 will be displayed. Because no HTML interpretation is going on, the traceback
529 Common problems and solutions
530 -----------------------------
532 * Most HTTP servers buffer the output from CGI scripts until the script is
533 completed. This means that it is not possible to display a progress report on
534 the client's display while the script is running.
536 * Check the installation instructions above.
538 * Check the HTTP server's log files. (``tail -f logfile`` in a separate window
541 * Always check a script for syntax errors first, by doing something like
542 ``python script.py``.
544 * If your script does not have any syntax errors, try adding ``import cgitb;
545 cgitb.enable()`` to the top of the script.
547 * When invoking external programs, make sure they can be found. Usually, this
548 means using absolute path names --- :envvar:`PATH` is usually not set to a very
549 useful value in a CGI script.
551 * When reading or writing external files, make sure they can be read or written
552 by the userid under which your CGI script will be running: this is typically the
553 userid under which the web server is running, or some explicitly specified
554 userid for a web server's ``suexec`` feature.
556 * Don't try to give a CGI script a set-uid mode. This doesn't work on most
557 systems, and is a security liability as well.
559 .. rubric:: Footnotes
561 .. [#] Note that some recent versions of the HTML specification do state what order the
562 field values should be supplied in, but knowing whether a request was
563 received from a conforming browser, or even from a browser at all, is tedious