# `cgi` — Suporte a Common Gateway Interface

Código-fonte: Lib/cgi.py

Obsoleto desde a versão 3.11: The `cgi` module is deprecated (see PEP 594 for details and alternatives).

Módulo de suporte a scripts de Common Gateway Interface (CGI).

Este módulo define vários utilitários para uso por scripts CGI escritos em Python.

## Introdução

Um script CGI é chamado por um servidor HTTP, geralmente para processar a entrada do usuário enviada por meio de um elemento HTML `<FORM>` ou `<ISINDEX>`.

Na maioria das vezes, os scripts CGI residem no diretório especial `cgi-bin` do servidor. O servidor HTTP coloca todos os tipos de informações sobre a solicitação (como o nome do host do cliente, a URL solicitada, a string de consulta e muitos outros itens) no ambiente de shell do script, executa o script e envia a saída do script de volta para o cliente.

A entrada do script também está conectada ao cliente e, às vezes, os dados do formulário são lidos dessa forma; em outras ocasiões, os dados do formulário são transmitidos por meio da parte “string de consulta” da URL. Este módulo tem como objetivo cuidar dos diferentes casos e fornecer uma interface mais simples para o script Python. Ele também fornece vários utilitários que ajudam na depuração de scripts, e a última adição é o suporte para uploads de arquivos de um formulário (se o seu navegador permitir).

A saída de um script CGI deve consistir em duas seções, separadas por uma linha em branco. A primeira seção contém vários cabeçalhos, informando ao cliente que tipo de dados está seguindo. O código Python para gerar uma seção de cabeçalho mínima se parece com isto:

    print("Content-Type: text/html")    # HTML is following
    print()                             # blank line, end of headers

A segunda seção é geralmente HTML, o que permite que o software cliente exiba um texto bem formatado com cabeçalho, imagens em linha etc. Aqui está o código Python que imprime um pedaço simples de HTML

    print("<TITLE>CGI script output</TITLE>")
    print("<H1>This is my first CGI script</H1>")
    print("Hello, world!")

## Usando o módulo cgi

Comece escrevendo `import cgi`.

Ao escrever um novo script, considere adicionar estas linhas:

    import cgitb
    cgitb.enable()

This activates a special exception handler that will display detailed reports in the web browser if any errors occur. If you’d rather not show the guts of your program to users of your script, you can have the reports saved to files instead, with code like this:

    import cgitb
    cgitb.enable(display=0, logdir="/path/to/logdir")

É muito útil usar esse recurso durante o desenvolvimento do script. Os relatórios produzidos por `cgitb` fornecem informações que podem economizar muito tempo no rastreamento de bugs. Você sempre pode remover a linha `cgitb` mais tarde, quando tiver testado seu script e estiver confiante de que ele funciona corretamente.

To get at submitted form data, use the `FieldStorage` class. If the form contains non-ASCII characters, use the encoding keyword parameter set to the value of the encoding defined for the document. It is usually contained in the META tag in the HEAD section of the HTML document or by the Content-Type header. This reads the form contents from the standard input or the environment (depending on the value of various environment variables set according to the CGI standard). Since it may consume standard input, it should be instantiated only once.

A instância de `FieldStorage` pode ser indexada como um dicionário Python. Ela permite o teste de associação com o operador `in`, e também tem suporte ao método de dicionário padrão `keys()` e a função embutida `len()`. Os campos do formulário contendo strings vazias são ignorados e não aparecem no dicionário; para manter esses valores, forneça um valor verdadeiro para o parâmetro nnomeado opcional keep_blank_values ao criar a instância `FieldStorage`.

For instance, the following code (which assumes that the Content-Type header and blank line have already been printed) checks that the fields `name` and `addr` are both set to a non-empty string:

    form = cgi.FieldStorage()
    if "name" not in form or "addr" not in form:
        print("<H1>Error</H1>")
        print("Please fill in the name and addr fields.")
        return
    print("<p>name:", form["name"].value)
    print("<p>addr:", form["addr"].value)
    ...further form processing here...

Here the fields, accessed through `form[key]`, are themselves instances of `FieldStorage` (or `MiniFieldStorage`, depending on the form encoding). The `value` attribute of the instance yields the string value of the field. The `getvalue()` method returns this string value directly; it also accepts an optional second argument as a default to return if the requested key is not present.

If the submitted form data contains more than one field with the same name, the object retrieved by `form[key]` is not a `FieldStorage` or `MiniFieldStorage` instance but a list of such instances. Similarly, in this situation, `form.getvalue(key)` would return a list of strings. If you expect this possibility (when your HTML form contains multiple fields with the same name), use the `getlist()` method, which always returns a list of values (so that you do not need to special-case the single item case). For example, this code concatenates any number of username fields, separated by commas:

    value = form.getlist("username")
    usernames = ",".join(value)

If a field represents an uploaded file, accessing the value via the `value` attribute or the `getvalue()` method reads the entire file in memory as bytes. This may not be what you want. You can test for an uploaded file by testing either the `filename` attribute or the `file` attribute. You can then read the data from the `file` attribute before it is automatically closed as part of the garbage collection of the `FieldStorage` instance (the `read()` and `readline()` methods will return bytes):

    fileitem = form["userfile"]
    if fileitem.file:
        # It's an uploaded file; count lines
        linecount = 0
        while True:
            line = fileitem.file.readline()
            if not line: break
            linecount = linecount + 1

`FieldStorage` objects also support being used in a `with` statement, which will automatically close them when done.

If an error is encountered when obtaining the contents of an uploaded file (for example, when the user interrupts the form submission by clicking on a Back or Cancel button) the `done` attribute of the object for the field will be set to the value -1.

The file upload draft standard entertains the possibility of uploading multiple files from one field (using a recursive multipart/* encoding). When this occurs, the item will be a dictionary-like `FieldStorage` item. This can be determined by testing its `type` attribute, which should be multipart/form-data (or perhaps another MIME type matching multipart/*). In this case, it can be iterated over recursively just like the top-level form object.

When a form is submitted in the “old” format (as the query string or as a single data part of type application/x-www-form-urlencoded), the items will actually be instances of the class `MiniFieldStorage`. In this case, the `list`, `file`, and `filename` attributes are always `None`.

A form submitted via POST that also has a query string will contain both `FieldStorage` and `MiniFieldStorage` items.

Alterado na versão 3.4: The `file` attribute is automatically closed upon the garbage collection of the creating `FieldStorage` instance.

Alterado na versão 3.5: Added support for the context management protocol to the `FieldStorage` class.

## Interface de nível mais alto

The previous section explains how to read CGI form data using the `FieldStorage` class. This section describes a higher level interface which was added to this class to allow one to do it in a more readable and intuitive way. The interface doesn’t make the techniques described in previous sections obsolete — they are still useful to process file uploads efficiently, for example.

The interface consists of two simple methods. Using the methods you can process form data in a generic way, without the need to worry whether only one or more values were posted under one name.

In the previous section, you learned to write following code anytime you expected a user to post more than one value under one name:

    item = form.getvalue("item")
    if isinstance(item, list):
        # The user is requesting more than one item.
    else:
        # The user is requesting only one item.

This situation is common for example when a form contains a group of multiple checkboxes with the same name:

    <input type="checkbox" name="item" value="1" />
    <input type="checkbox" name="item" value="2" />

In most situations, however, there’s only one form control with a particular name in a form and then you expect and need only one value associated with this name. So you write a script containing for example this code:

    user = form.getvalue("user").upper()

The problem with the code is that you should never expect that a client will provide valid input to your scripts. For example, if a curious user appends another `user=foo` pair to the query string, then the script would crash, because in this situation the `getvalue("user")` method call returns a list instead of a string. Calling the `upper()` method on a list is not valid (since lists do not have a method of this name) and results in an `AttributeError` exception.

Therefore, the appropriate way to read form data values was to always use the code which checks whether the obtained value is a single value or a list of values. That’s annoying and leads to less readable scripts.

A more convenient approach is to use the methods `getfirst()` and `getlist()` provided by this higher level interface.

`FieldStorage.``getfirst`(name, default=None)

  This method always returns only one value associated with form field name. The method returns only the first value in case that more values were posted under such name. Please note that the order in which the values are received may vary from browser to browser and should not be counted on. 1 If no such form field or value exists then the method returns the value specified by the optional parameter default. This parameter defaults to `None` if not specified.

`FieldStorage.``getlist`(name)

  This method always returns a list of values associated with form field name. The method returns an empty list if no such form field or value exists for name. It returns a list consisting of one item if only one such value exists.

Using these methods you can write nice compact code:

    import cgi
    form = cgi.FieldStorage()
    user = form.getfirst("user", "").upper()    # This way it's safe.
    for item in form.getlist("item"):
        do_something(item)

## Funções

These are useful if you want more control, or if you want to employ some of the algorithms implemented in this module in other circumstances.

`cgi.``parse`(fp=None, environ=os.environ, keep_blank_values=False, strict_parsing=False, separator='&')

  Parse a query in the environment or from a file (the file defaults to `sys.stdin`). The keep_blank_values, strict_parsing and separator parameters are passed to `urllib.parse.parse_qs()` unchanged.

`cgi.``parse_multipart`(fp, pdict, encoding='utf-8', errors='replace', separator='&')

  Parse input of type multipart/form-data (for file uploads). Arguments are fp for the input file, pdict for a dictionary containing other parameters in the Content-Type header, and encoding, the request encoding.

  Returns a dictionary just like `urllib.parse.parse_qs()`: keys are the field names, each value is a list of values for that field. For non-file fields, the value is a list of strings.

  This is easy to use but not much good if you are expecting megabytes to be uploaded — in that case, use the `FieldStorage` class instead which is much more flexible.

  Alterado na versão 3.7: Added the encoding and errors parameters. For non-file fields, the value is now a list of strings, not bytes.

  Alterado na versão 3.10: Added the separator parameter.

`cgi.``parse_header`(string)

  Parse a MIME header (such as Content-Type) into a main value and a dictionary of parameters.

`cgi.``test`()

  Robust test CGI script, usable as main program. Writes minimal HTTP headers and formats all information provided to the script in HTML format.

`cgi.``print_environ`()

  Format the shell environment in HTML.

`cgi.``print_form`(form)

  Format a form in HTML.

`cgi.``print_directory`()

  Format the current directory in HTML.

`cgi.``print_environ_usage`()

  Print a list of useful (used by CGI) environment variables in HTML.

## Caring about security

There’s one important rule: if you invoke an external program (via `os.system()`, `os.popen()` or other functions with similar functionality), make very sure you don’t pass arbitrary strings received from the client to the shell. This is a well-known security hole whereby clever hackers anywhere on the web can exploit a gullible CGI script to invoke arbitrary shell commands. Even parts of the URL or field names cannot be trusted, since the request doesn’t have to come from your form!

To be on the safe side, if you must pass a string gotten from a form to a shell command, you should make sure the string contains only alphanumeric characters, dashes, underscores, and periods.

## Installing your CGI script on a Unix system

Read the documentation for your HTTP server and check with your local system administrator to find the directory where CGI scripts should be installed; usually this is in a directory `cgi-bin` in the server tree.

Make sure that your script is readable and executable by “others”; the Unix file mode should be `0o755` octal (use `chmod 0755 filename`). Make sure that the first line of the script contains `#!` starting in column 1 followed by the pathname of the Python interpreter, for instance:

    #!/usr/local/bin/python

Make sure the Python interpreter exists and is executable by “others”.

Make sure that any files your script needs to read or write are readable or writable, respectively, by “others” — their mode should be `0o644` for readable and `0o666` for writable. This is because, for security reasons, the HTTP server executes your script as user “nobody”, without any special privileges. It can only read (write, execute) files that everybody can read (write, execute). The current directory at execution time is also different (it is usually the server’s cgi-bin directory) and the set of environment variables is also different from what you get when you log in. In particular, don’t count on the shell’s search path for executables (`PATH`) or the Python module search path (`PYTHONPATH`) to be set to anything interesting.

If you need to load modules from a directory which is not on Python’s default module search path, you can change the path in your script, before importing other modules. For example:

    import sys
    sys.path.insert(0, "/usr/home/joe/lib/python")
    sys.path.insert(0, "/usr/local/lib/python")

(This way, the directory inserted last will be searched first!)

Instructions for non-Unix systems will vary; check your HTTP server’s documentation (it will usually have a section on CGI scripts).

## Testing your CGI script

Unfortunately, a CGI script will generally not run when you try it from the command line, and a script that works perfectly from the command line may fail mysteriously when run from the server. There’s one reason why you should still test your script from the command line: if it contains a syntax error, the Python interpreter won’t execute it at all, and the HTTP server will most likely send a cryptic error to the client.

Assuming your script has no syntax errors, yet it does not work, you have no choice but to read the next section.

## Debugging CGI scripts

First of all, check for trivial installation errors — reading the section above on installing your CGI script carefully can save you a lot of time. If you wonder whether you have understood the installation procedure correctly, try installing a copy of this module file (`cgi.py`) as a CGI script. When invoked as a script, the file will dump its environment and the contents of the form in HTML format. Give it the right mode etc., and send it a request. If it’s installed in the standard `cgi-bin` directory, it should be possible to send it a request by entering a URL into your browser of the form:

    http://yourhostname/cgi-bin/cgi.py?name=Joe+Blow&addr=At+Home

If this gives an error of type 404, the server cannot find the script – perhaps you need to install it in a different directory. If it gives another error, there’s an installation problem that you should fix before trying to go any further. If you get a nicely formatted listing of the environment and form content (in this example, the fields should be listed as “addr” with value “At Home” and “name” with value “Joe Blow”), the `cgi.py` script has been installed correctly. If you follow the same procedure for your own script, you should now be able to debug it.

The next step could be to call the `cgi` module’s `test()` function from your script: replace its main code with the single statement

    cgi.test()

This should produce the same results as those gotten from installing the `cgi.py` file itself.

When an ordinary Python script raises an unhandled exception (for whatever reason: of a typo in a module name, a file that can’t be opened, etc.), the Python interpreter prints a nice traceback and exits. While the Python interpreter will still do this when your CGI script raises an exception, most likely the traceback will end up in one of the HTTP server’s log files, or be discarded altogether.

Fortunately, once you have managed to get your script to execute some code, you can easily send tracebacks to the web browser using the `cgitb` module. If you haven’t done so already, just add the lines:

    import cgitb
    cgitb.enable()

to the top of your script. Then try running it again; when a problem occurs, you should see a detailed report that will likely make apparent the cause of the crash.

If you suspect that there may be a problem in importing the `cgitb` module, you can use an even more robust approach (which only uses built-in modules):

    import sys
    sys.stderr = sys.stdout
    print("Content-Type: text/plain")
    print()
    ...your code here...

This relies on the Python interpreter to print the traceback. The content type of the output is set to plain text, which disables all HTML processing. If your script works, the raw HTML will be displayed by your client. If it raises an exception, most likely after the first two lines have been printed, a traceback will be displayed. Because no HTML interpretation is going on, the traceback will be readable.

## Common problems and solutions

- Most HTTP servers buffer the output from CGI scripts until the script is completed. This means that it is not possible to display a progress report on the client’s display while the script is running.

- Check the installation instructions above.

- Check the HTTP server’s log files. (`tail -f logfile` in a separate window may be useful!)

- Always check a script for syntax errors first, by doing something like `python script.py`.

- If your script does not have any syntax errors, try adding `import cgitb; cgitb.enable()` to the top of the script.

- When invoking external programs, make sure they can be found. Usually, this means using absolute path names — `PATH` is usually not set to a very useful value in a CGI script.

- When reading or writing external files, make sure they can be read or written by the userid under which your CGI script will be running: this is typically the userid under which the web server is running, or some explicitly specified userid for a web server’s `suexec` feature.

- Don’t try to give a CGI script a set-uid mode. This doesn’t work on most systems, and is a security liability as well.

Notas de rodapé

1

  Note that some recent versions of the HTML specification do state what order the field values should be supplied in, but knowing whether a request was received from a conforming browser, or even from a browser at all, is tedious and error-prone.