/Doc/library/cgi.rst

http://unladen-swallow.googlecode.com/ · ReStructuredText · 537 lines · 383 code · 154 blank · 0 comment · 0 complexity · 6e1f46b2abc354cde979506329631a33 MD5 · raw file

  1. :mod:`cgi` --- Common Gateway Interface support.
  2. ================================================
  3. .. module:: cgi
  4. :synopsis: Helpers for running Python scripts via the Common Gateway Interface.
  5. .. index::
  6. pair: WWW; server
  7. pair: CGI; protocol
  8. pair: HTTP; protocol
  9. pair: MIME; headers
  10. single: URL
  11. single: Common Gateway Interface
  12. Support module for Common Gateway Interface (CGI) scripts.
  13. This module defines a number of utilities for use by CGI scripts written in
  14. Python.
  15. Introduction
  16. ------------
  17. .. _cgi-intro:
  18. A CGI script is invoked by an HTTP server, usually to process user input
  19. submitted through an HTML ``<FORM>`` or ``<ISINDEX>`` element.
  20. Most often, CGI scripts live in the server's special :file:`cgi-bin` directory.
  21. The HTTP server places all sorts of information about the request (such as the
  22. client's hostname, the requested URL, the query string, and lots of other
  23. goodies) in the script's shell environment, executes the script, and sends the
  24. script's output back to the client.
  25. The script's input is connected to the client too, and sometimes the form data
  26. is read this way; at other times the form data is passed via the "query string"
  27. part of the URL. This module is intended to take care of the different cases
  28. and provide a simpler interface to the Python script. It also provides a number
  29. of utilities that help in debugging scripts, and the latest addition is support
  30. for file uploads from a form (if your browser supports it).
  31. The output of a CGI script should consist of two sections, separated by a blank
  32. line. The first section contains a number of headers, telling the client what
  33. kind of data is following. Python code to generate a minimal header section
  34. looks like this::
  35. print "Content-Type: text/html" # HTML is following
  36. print # blank line, end of headers
  37. The second section is usually HTML, which allows the client software to display
  38. nicely formatted text with header, in-line images, etc. Here's Python code that
  39. prints a simple piece of HTML::
  40. print "<TITLE>CGI script output</TITLE>"
  41. print "<H1>This is my first CGI script</H1>"
  42. print "Hello, world!"
  43. .. _using-the-cgi-module:
  44. Using the cgi module
  45. --------------------
  46. Begin by writing ``import cgi``. Do not use ``from cgi import *`` --- the
  47. module defines all sorts of names for its own use or for backward compatibility
  48. that you don't want in your namespace.
  49. When you write a new script, consider adding these lines::
  50. import cgitb
  51. cgitb.enable()
  52. This activates a special exception handler that will display detailed reports in
  53. the Web browser if any errors occur. If you'd rather not show the guts of your
  54. program to users of your script, you can have the reports saved to files
  55. instead, with code like this::
  56. import cgitb
  57. cgitb.enable(display=0, logdir="/tmp")
  58. It's very helpful to use this feature during script development. The reports
  59. produced by :mod:`cgitb` provide information that can save you a lot of time in
  60. tracking down bugs. You can always remove the ``cgitb`` line later when you
  61. have tested your script and are confident that it works correctly.
  62. To get at submitted form data, it's best to use the :class:`FieldStorage` class.
  63. The other classes defined in this module are provided mostly for backward
  64. compatibility. Instantiate it exactly once, without arguments. This reads the
  65. form contents from standard input or the environment (depending on the value of
  66. various environment variables set according to the CGI standard). Since it may
  67. consume standard input, it should be instantiated only once.
  68. The :class:`FieldStorage` instance can be indexed like a Python dictionary, and
  69. also supports the standard dictionary methods :meth:`has_key` and :meth:`keys`.
  70. The built-in :func:`len` is also supported. Form fields containing empty
  71. strings are ignored and do not appear in the dictionary; to keep such values,
  72. provide a true value for the optional *keep_blank_values* keyword parameter when
  73. creating the :class:`FieldStorage` instance.
  74. For instance, the following code (which assumes that the
  75. :mailheader:`Content-Type` header and blank line have already been printed)
  76. checks that the fields ``name`` and ``addr`` are both set to a non-empty
  77. string::
  78. form = cgi.FieldStorage()
  79. if not (form.has_key("name") and form.has_key("addr")):
  80. print "<H1>Error</H1>"
  81. print "Please fill in the name and addr fields."
  82. return
  83. print "<p>name:", form["name"].value
  84. print "<p>addr:", form["addr"].value
  85. ...further form processing here...
  86. Here the fields, accessed through ``form[key]``, are themselves instances of
  87. :class:`FieldStorage` (or :class:`MiniFieldStorage`, depending on the form
  88. encoding). The :attr:`value` attribute of the instance yields the string value
  89. of the field. The :meth:`getvalue` method returns this string value directly;
  90. it also accepts an optional second argument as a default to return if the
  91. requested key is not present.
  92. If the submitted form data contains more than one field with the same name, the
  93. object retrieved by ``form[key]`` is not a :class:`FieldStorage` or
  94. :class:`MiniFieldStorage` instance but a list of such instances. Similarly, in
  95. this situation, ``form.getvalue(key)`` would return a list of strings. If you
  96. expect this possibility (when your HTML form contains multiple fields with the
  97. same name), use the :func:`getlist` function, which always returns a list of
  98. values (so that you do not need to special-case the single item case). For
  99. example, this code concatenates any number of username fields, separated by
  100. commas::
  101. value = form.getlist("username")
  102. usernames = ",".join(value)
  103. If a field represents an uploaded file, accessing the value via the
  104. :attr:`value` attribute or the :func:`getvalue` method reads the entire file in
  105. memory as a string. This may not be what you want. You can test for an uploaded
  106. file by testing either the :attr:`filename` attribute or the :attr:`file`
  107. attribute. You can then read the data at leisure from the :attr:`file`
  108. attribute::
  109. fileitem = form["userfile"]
  110. if fileitem.file:
  111. # It's an uploaded file; count lines
  112. linecount = 0
  113. while 1:
  114. line = fileitem.file.readline()
  115. if not line: break
  116. linecount = linecount + 1
  117. If an error is encountered when obtaining the contents of an uploaded file
  118. (for example, when the user interrupts the form submission by clicking on
  119. a Back or Cancel button) the :attr:`done` attribute of the object for the
  120. field will be set to the value -1.
  121. The file upload draft standard entertains the possibility of uploading multiple
  122. files from one field (using a recursive :mimetype:`multipart/\*` encoding).
  123. When this occurs, the item will be a dictionary-like :class:`FieldStorage` item.
  124. This can be determined by testing its :attr:`type` attribute, which should be
  125. :mimetype:`multipart/form-data` (or perhaps another MIME type matching
  126. :mimetype:`multipart/\*`). In this case, it can be iterated over recursively
  127. just like the top-level form object.
  128. When a form is submitted in the "old" format (as the query string or as a single
  129. data part of type :mimetype:`application/x-www-form-urlencoded`), the items will
  130. actually be instances of the class :class:`MiniFieldStorage`. In this case, the
  131. :attr:`list`, :attr:`file`, and :attr:`filename` attributes are always ``None``.
  132. A form submitted via POST that also has a query string will contain both
  133. :class:`FieldStorage` and :class:`MiniFieldStorage` items.
  134. Higher Level Interface
  135. ----------------------
  136. .. versionadded:: 2.2
  137. The previous section explains how to read CGI form data using the
  138. :class:`FieldStorage` class. This section describes a higher level interface
  139. which was added to this class to allow one to do it in a more readable and
  140. intuitive way. The interface doesn't make the techniques described in previous
  141. sections obsolete --- they are still useful to process file uploads efficiently,
  142. for example.
  143. .. XXX: Is this true ?
  144. The interface consists of two simple methods. Using the methods you can process
  145. form data in a generic way, without the need to worry whether only one or more
  146. values were posted under one name.
  147. In the previous section, you learned to write following code anytime you
  148. expected a user to post more than one value under one name::
  149. item = form.getvalue("item")
  150. if isinstance(item, list):
  151. # The user is requesting more than one item.
  152. else:
  153. # The user is requesting only one item.
  154. This situation is common for example when a form contains a group of multiple
  155. checkboxes with the same name::
  156. <input type="checkbox" name="item" value="1" />
  157. <input type="checkbox" name="item" value="2" />
  158. In most situations, however, there's only one form control with a particular
  159. name in a form and then you expect and need only one value associated with this
  160. name. So you write a script containing for example this code::
  161. user = form.getvalue("user").upper()
  162. The problem with the code is that you should never expect that a client will
  163. provide valid input to your scripts. For example, if a curious user appends
  164. another ``user=foo`` pair to the query string, then the script would crash,
  165. because in this situation the ``getvalue("user")`` method call returns a list
  166. instead of a string. Calling the :meth:`toupper` method on a list is not valid
  167. (since lists do not have a method of this name) and results in an
  168. :exc:`AttributeError` exception.
  169. Therefore, the appropriate way to read form data values was to always use the
  170. code which checks whether the obtained value is a single value or a list of
  171. values. That's annoying and leads to less readable scripts.
  172. A more convenient approach is to use the methods :meth:`getfirst` and
  173. :meth:`getlist` provided by this higher level interface.
  174. .. method:: FieldStorage.getfirst(name[, default])
  175. This method always returns only one value associated with form field *name*.
  176. The method returns only the first value in case that more values were posted
  177. under such name. Please note that the order in which the values are received
  178. may vary from browser to browser and should not be counted on. [#]_ If no such
  179. form field or value exists then the method returns the value specified by the
  180. optional parameter *default*. This parameter defaults to ``None`` if not
  181. specified.
  182. .. method:: FieldStorage.getlist(name)
  183. This method always returns a list of values associated with form field *name*.
  184. The method returns an empty list if no such form field or value exists for
  185. *name*. It returns a list consisting of one item if only one such value exists.
  186. Using these methods you can write nice compact code::
  187. import cgi
  188. form = cgi.FieldStorage()
  189. user = form.getfirst("user", "").upper() # This way it's safe.
  190. for item in form.getlist("item"):
  191. do_something(item)
  192. Old classes
  193. -----------
  194. .. deprecated:: 2.6
  195. These classes, present in earlier versions of the :mod:`cgi` module, are
  196. still supported for backward compatibility. New applications should use the
  197. :class:`FieldStorage` class.
  198. :class:`SvFormContentDict` stores single value form content as dictionary; it
  199. assumes each field name occurs in the form only once.
  200. :class:`FormContentDict` stores multiple value form content as a dictionary (the
  201. form items are lists of values). Useful if your form contains multiple fields
  202. with the same name.
  203. Other classes (:class:`FormContent`, :class:`InterpFormContentDict`) are present
  204. for backwards compatibility with really old applications only.
  205. .. _functions-in-cgi-module:
  206. Functions
  207. ---------
  208. These are useful if you want more control, or if you want to employ some of the
  209. algorithms implemented in this module in other circumstances.
  210. .. function:: parse(fp[, keep_blank_values[, strict_parsing]])
  211. Parse a query in the environment or from a file (the file defaults to
  212. ``sys.stdin``). The *keep_blank_values* and *strict_parsing* parameters are
  213. passed to :func:`urlparse.parse_qs` unchanged.
  214. .. function:: parse_qs(qs[, keep_blank_values[, strict_parsing]])
  215. This function is deprecated in this module. Use :func:`urlparse.parse_qs`
  216. instead. It is maintained here only for backward compatiblity.
  217. .. function:: parse_qsl(qs[, keep_blank_values[, strict_parsing]])
  218. This function is deprecated in this module. Use :func:`urlparse.parse_qsl`
  219. instead. It is maintained here only for backward compatiblity.
  220. .. function:: parse_multipart(fp, pdict)
  221. Parse input of type :mimetype:`multipart/form-data` (for file uploads).
  222. Arguments are *fp* for the input file and *pdict* for a dictionary containing
  223. other parameters in the :mailheader:`Content-Type` header.
  224. Returns a dictionary just like :func:`urlparse.parse_qs` keys are the field names, each
  225. value is a list of values for that field. This is easy to use but not much good
  226. if you are expecting megabytes to be uploaded --- in that case, use the
  227. :class:`FieldStorage` class instead which is much more flexible.
  228. Note that this does not parse nested multipart parts --- use
  229. :class:`FieldStorage` for that.
  230. .. function:: parse_header(string)
  231. Parse a MIME header (such as :mailheader:`Content-Type`) into a main value and a
  232. dictionary of parameters.
  233. .. function:: test()
  234. Robust test CGI script, usable as main program. Writes minimal HTTP headers and
  235. formats all information provided to the script in HTML form.
  236. .. function:: print_environ()
  237. Format the shell environment in HTML.
  238. .. function:: print_form(form)
  239. Format a form in HTML.
  240. .. function:: print_directory()
  241. Format the current directory in HTML.
  242. .. function:: print_environ_usage()
  243. Print a list of useful (used by CGI) environment variables in HTML.
  244. .. function:: escape(s[, quote])
  245. Convert the characters ``'&'``, ``'<'`` and ``'>'`` in string *s* to HTML-safe
  246. sequences. Use this if you need to display text that might contain such
  247. characters in HTML. If the optional flag *quote* is true, the quotation mark
  248. character (``'"'``) is also translated; this helps for inclusion in an HTML
  249. attribute value, as in ``<A HREF="...">``. If the value to be quoted might
  250. include single- or double-quote characters, or both, consider using the
  251. :func:`quoteattr` function in the :mod:`xml.sax.saxutils` module instead.
  252. .. _cgi-security:
  253. Caring about security
  254. ---------------------
  255. .. index:: pair: CGI; security
  256. There's one important rule: if you invoke an external program (via the
  257. :func:`os.system` or :func:`os.popen` functions. or others with similar
  258. functionality), make very sure you don't pass arbitrary strings received from
  259. the client to the shell. This is a well-known security hole whereby clever
  260. hackers anywhere on the Web can exploit a gullible CGI script to invoke
  261. arbitrary shell commands. Even parts of the URL or field names cannot be
  262. trusted, since the request doesn't have to come from your form!
  263. To be on the safe side, if you must pass a string gotten from a form to a shell
  264. command, you should make sure the string contains only alphanumeric characters,
  265. dashes, underscores, and periods.
  266. Installing your CGI script on a Unix system
  267. -------------------------------------------
  268. Read the documentation for your HTTP server and check with your local system
  269. administrator to find the directory where CGI scripts should be installed;
  270. usually this is in a directory :file:`cgi-bin` in the server tree.
  271. Make sure that your script is readable and executable by "others"; the Unix file
  272. mode should be ``0755`` octal (use ``chmod 0755 filename``). Make sure that the
  273. first line of the script contains ``#!`` starting in column 1 followed by the
  274. pathname of the Python interpreter, for instance::
  275. #!/usr/local/bin/python
  276. Make sure the Python interpreter exists and is executable by "others".
  277. Make sure that any files your script needs to read or write are readable or
  278. writable, respectively, by "others" --- their mode should be ``0644`` for
  279. readable and ``0666`` for writable. This is because, for security reasons, the
  280. HTTP server executes your script as user "nobody", without any special
  281. privileges. It can only read (write, execute) files that everybody can read
  282. (write, execute). The current directory at execution time is also different (it
  283. is usually the server's cgi-bin directory) and the set of environment variables
  284. is also different from what you get when you log in. In particular, don't count
  285. on the shell's search path for executables (:envvar:`PATH`) or the Python module
  286. search path (:envvar:`PYTHONPATH`) to be set to anything interesting.
  287. If you need to load modules from a directory which is not on Python's default
  288. module search path, you can change the path in your script, before importing
  289. other modules. For example::
  290. import sys
  291. sys.path.insert(0, "/usr/home/joe/lib/python")
  292. sys.path.insert(0, "/usr/local/lib/python")
  293. (This way, the directory inserted last will be searched first!)
  294. Instructions for non-Unix systems will vary; check your HTTP server's
  295. documentation (it will usually have a section on CGI scripts).
  296. Testing your CGI script
  297. -----------------------
  298. Unfortunately, a CGI script will generally not run when you try it from the
  299. command line, and a script that works perfectly from the command line may fail
  300. mysteriously when run from the server. There's one reason why you should still
  301. test your script from the command line: if it contains a syntax error, the
  302. Python interpreter won't execute it at all, and the HTTP server will most likely
  303. send a cryptic error to the client.
  304. Assuming your script has no syntax errors, yet it does not work, you have no
  305. choice but to read the next section.
  306. Debugging CGI scripts
  307. ---------------------
  308. .. index:: pair: CGI; debugging
  309. First of all, check for trivial installation errors --- reading the section
  310. above on installing your CGI script carefully can save you a lot of time. If
  311. you wonder whether you have understood the installation procedure correctly, try
  312. installing a copy of this module file (:file:`cgi.py`) as a CGI script. When
  313. invoked as a script, the file will dump its environment and the contents of the
  314. form in HTML form. Give it the right mode etc, and send it a request. If it's
  315. installed in the standard :file:`cgi-bin` directory, it should be possible to
  316. send it a request by entering a URL into your browser of the form::
  317. http://yourhostname/cgi-bin/cgi.py?name=Joe+Blow&addr=At+Home
  318. If this gives an error of type 404, the server cannot find the script -- perhaps
  319. you need to install it in a different directory. If it gives another error,
  320. there's an installation problem that you should fix before trying to go any
  321. further. If you get a nicely formatted listing of the environment and form
  322. content (in this example, the fields should be listed as "addr" with value "At
  323. Home" and "name" with value "Joe Blow"), the :file:`cgi.py` script has been
  324. installed correctly. If you follow the same procedure for your own script, you
  325. should now be able to debug it.
  326. The next step could be to call the :mod:`cgi` module's :func:`test` function
  327. from your script: replace its main code with the single statement ::
  328. cgi.test()
  329. This should produce the same results as those gotten from installing the
  330. :file:`cgi.py` file itself.
  331. When an ordinary Python script raises an unhandled exception (for whatever
  332. reason: of a typo in a module name, a file that can't be opened, etc.), the
  333. Python interpreter prints a nice traceback and exits. While the Python
  334. interpreter will still do this when your CGI script raises an exception, most
  335. likely the traceback will end up in one of the HTTP server's log files, or be
  336. discarded altogether.
  337. Fortunately, once you have managed to get your script to execute *some* code,
  338. you can easily send tracebacks to the Web browser using the :mod:`cgitb` module.
  339. If you haven't done so already, just add the lines::
  340. import cgitb
  341. cgitb.enable()
  342. to the top of your script. Then try running it again; when a problem occurs,
  343. you should see a detailed report that will likely make apparent the cause of the
  344. crash.
  345. If you suspect that there may be a problem in importing the :mod:`cgitb` module,
  346. you can use an even more robust approach (which only uses built-in modules)::
  347. import sys
  348. sys.stderr = sys.stdout
  349. print "Content-Type: text/plain"
  350. print
  351. ...your code here...
  352. This relies on the Python interpreter to print the traceback. The content type
  353. of the output is set to plain text, which disables all HTML processing. If your
  354. script works, the raw HTML will be displayed by your client. If it raises an
  355. exception, most likely after the first two lines have been printed, a traceback
  356. will be displayed. Because no HTML interpretation is going on, the traceback
  357. will be readable.
  358. Common problems and solutions
  359. -----------------------------
  360. * Most HTTP servers buffer the output from CGI scripts until the script is
  361. completed. This means that it is not possible to display a progress report on
  362. the client's display while the script is running.
  363. * Check the installation instructions above.
  364. * Check the HTTP server's log files. (``tail -f logfile`` in a separate window
  365. may be useful!)
  366. * Always check a script for syntax errors first, by doing something like
  367. ``python script.py``.
  368. * If your script does not have any syntax errors, try adding ``import cgitb;
  369. cgitb.enable()`` to the top of the script.
  370. * When invoking external programs, make sure they can be found. Usually, this
  371. means using absolute path names --- :envvar:`PATH` is usually not set to a very
  372. useful value in a CGI script.
  373. * When reading or writing external files, make sure they can be read or written
  374. by the userid under which your CGI script will be running: this is typically the
  375. userid under which the web server is running, or some explicitly specified
  376. userid for a web server's ``suexec`` feature.
  377. * Don't try to give a CGI script a set-uid mode. This doesn't work on most
  378. systems, and is a security liability as well.
  379. .. rubric:: Footnotes
  380. .. [#] Note that some recent versions of the HTML specification do state what order the
  381. field values should be supplied in, but knowing whether a request was
  382. received from a conforming browser, or even from a browser at all, is tedious
  383. and error-prone.