When to use GET and POST

In HTTP and/or HTML, there are two (main?) types of submissions: GET and POST. I have always had a hard time determining when to use GET and when to use POST. In other words, what is the main difference between GET and POST?

Quite simply, if the submission is reading data, without making any changes, use GET. If your submission will be making changes, or causing side-effects, use POST. For example, when doing a query, such as a Google search, the form should use GET. If you are creating a new account with Yahoo! mail, the form should use POST. The Google search is reading data and new account in Yahoo! mail is changing things.

Simple enough, right? Not so, as there are some situations where either could work. One of the best descriptions of the problem I have read is Methods GET and POST in HTML forms – what’s the difference? And here is what I learned from it (you might learn something else reading the same words):

When doing a submission which will not make changes use GET. When making changes, use POST. But you may want to use POST instead of GET in the following (major?) case: when you don’t want the data you submit to become a part of the URL. When using GET, the form you submit becomes a part of the URL. So if you have a couple fields, say myname and mynumber, using GET your URL might look like http://www.mydomain.com/someform.html/?myname=codeghar&mynumber=1234 after submission. The biggest benefit is that you can bookmark this URL and visit it in future as just another link. The biggest disadvantage, in my opinion, is when you have multiple fields, the fields and their data becomes part of the URL, thus making for ugly URLs. So instead of a neat looking, small URL, you get one huge string.

Don’t get me wrong: a useful URL, even if ugly, should be preferred to an unfriendly, pretty URL. But if you want to pretty-fy your URLs, use POST instead of GET. And with a pretty URL, your user doesn’t have to know the inner workings of your form. They can still look at the source code of the page to see what’s going on, but only if they want to. Encoding the form data into a URL forces them to deal with the data even if they don’t want to.

The second benefit of using POST is that if your form contains non-ASCII data, it doesn’t form a part of the URL, which might be a good thing if your HTTP server is unable to handle this data in the URL. I don’t know, maybe all modern servers or intermediary devices can handle this stuff easily. But better safe than sorry, eh?

So from today my best practice is thus: if the form has a small number of fields, showing the submitted data in the URL is not a problem, and/or URL should be bookmark-able for future reference, use GET if there are no side-effects. If none of these requirements is met, use POST.

One concern I have is: if using HTTPS, is the URL sent in the secure tunnel or is it plaintext for all to see? According to the responses at HTTPS – is URL string itself secure??, the URL should be encrypted before being sent to the server as it is sent as part of the tunnel rather than a separate string. I think it would depend on the implementation of the client and server (I could be wrong in thinking this).

Don’t take my understanding of the situation as the final word. Read as much as you can on the subject to form your own best practice. And if you share your understanding and best practice with us, it would help us as well.

Good reads and hat tips: URIs, Addressability, and the use of HTTP GET and POST; Methods GET and POST in HTML forms – what’s the difference?; Post/Redirect/Get;

Django in Debian Lenny

Installing Django in Debian is very similar to in Ubuntu. Here we will use Postgresql so there will be a slight difference from when using MySQL.

sudo aptitude install postgresql python-psycopg2 python-django

Django in CentOS

This post has been written using CentOS 5.2, but these instructions may also work for other versions. Just let us know if they don’t.

Install EPEL

Extra Packages for Enterprise Linux (EPEL) is “a repository of high-quality add-on packages that complement the Fedora-based Red Hat Enterprise Linux [...] and its compatible spinoffs such as CentOS or Scientific Linux.” You need this repository to install Django from a package. Another option is to download source and compile yourself. This guide, however, will be using packages. So just follow the instructions to add EPEL repository, which state:

su -c 'rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm'

Install Django

To install django from EPEL, just run the following command:

sudo yum install Django

Notice the uppercase ‘D’ in the name of the package. Django is installed in /usr/lib/python2.4/site-packages/django/ and it should already be included in the path.

Test Django

To make sure everything was installed properly, try to create a simple new project.

django-admin.py startproject /home/me/mynewproject

If a directory with the same name and some standard django sub-directories are created, then your installation was successful.

Choosing a Linux Distribution

Recently I have had more time to work with Linux. I had been using Ubuntu in some way for two years when I needed to set up Linux on a few years old server. Since I was comfortable with Ubuntu, I thought I might as well go ahead and use it. But then I found out that there were other alternatives as well. This caused a headache which still isn’t resolved to this day. Which distribution is the best to get hands-on, real world experience with?

Comfort

You have to look at your comfort level when choosing a distribution. If you are familiar with something, even in passing, it would be an easier path to go with what you know. On the other hand, all distributions may be different but they have more in common than there are differences. So learning another distribution style is not as difficult as one might expect.

Hardware Support

If the distribution you choose is not able to function on the hardware you have available, you should not choose it. If you can get it to work, with or without a lot of effort, all the power to you. If, however, you can’t get it to work, you might as well look for another option. I went ahead with Ubuntu on the server because it supported all its hardware out of the box. I did not have to tweak anything or waste a lot of time. On the same server I was unable to install CentOS because Red Hat had dropped support for server’s RAID card in its current distribution.

Purpose

For what purpose are you using a distribution? Is it going to be for starting out, testing, development, or deployment? For all these scenarios, there are many distributions fitting them just fine. For starting out, a friendly distribution like Ubuntu could work. If you are testing Linux for its feasibility in your environment, just about any distribution would work. A distribution for doing development work should be fast moving with new technology so that you can use it to its fullest extent. If it’s for production deployment, being conservative in your selection is recommended.

Cutting Edge Technology

Some distributions strive to be on the cutting-edge. I count Fedora, openSUSE, and Ubuntu in this category. They release new stuff every few months. So you get to work with what’s new. For example, on Ubuntu, I found Django packages ready to install and work. Since I wanted a package and I found it, I was able to start working. I did not have to jump through hoops just to get to the point where I would be able to work.

Enterprise

Yes, an enterprise version would be more stable and maybe more secure. But it is also less likely to include new technology in an easily accessible format. Taking the example of Django, I have not found any tutorial on the web to install it on CentOS using an RPM package. All tutorials I have read ask you to download and install from source. Yes, it’s the traditional way to do things but if package management is the future, we should look for packages first and source code later. Now if I am developing and deploying an application developed with Django, I want to have the peace of mind that I installed a package that had been tested to work well with the whole operating system, and not something I installed without knowing how it would turn out.

To me this is the most important point after hardware support. I am willing to learn a whole another distribution if it is enterprise level with great hardware support but also keeps up with new technology. Since not one distribution will always fill these requirements, we have to look at the best tool for the job at hand.

Security

I was shocked to learn a few days ago that Ubuntu server’s default firewall policy was to accept all traffic. CentOS, on the other hand, has a pretty aggressive firewall policy. Combined with recent scandal of Debian and OpenSSL, it has dented my confidence in Ubuntu. It’s not that Ubuntu is insecure, it’s just the appearance of security in the ecosystem is absent (to me, at least). It’s also not that these things cannot be rectified by me, it’s that why would I need to take an extra step when a prudent decision could do it for me in the first place.

Another aspect I look to is being root. Does one have to actually be root or would sudo do? I like the sudo model better since it forces you to actually type your permission when doing critical work. Yes, if you are careful su and su - would work as well as sudo. But I like the added carefulness of sudo. So the first thing I do after installing a distribution is to see if it has sudo and then enable it for at least one user.

Support

Support is a very important part of decision-making process. Support may be of three kinds: distribution creator, third-party professional, and community and friends. Support includes help as well as software updates. One can get help from many sources, and community is an essential part of this support ecosystem. It can get you started and get you out of trouble. Almost all (ok, maybe all) distributions provide software updates. Then there is an extra level of support which we know as enterprise or corporate support (think Red Hat). It is provided by either the creators and maintainer of the distribution or from third-party entities.

For a home user, software updates and community support should be sufficient. For a business, however, ‘corporate’ support is essential on production systems. Businesses like to pay someone to get extra insurance in case it is needed. If a server is essential to business operations, it is very important that the team running the server knows what it is doing, has community support for minor issues, and corporate support when things go really bad.

Red Hat, Novell, and Canonical provide this kind of support as they create their distributions. Of course, if you have a good team running your servers, you may not need to get corporate support. But if your manager is a non-technical person, she will most probably require it. And if it’s not your money being spent, why argue?

Conclusion

This was meant to be a discussion of factors I would look into when choosing a distribution. Nothing more, nothing less.

Disclaimer: I have edited, and will edit, this post as new arguments come up.

Django in Ubuntu

As I use Django in Ubuntu, I would like to point out little quirks here.

Install Django

Installing Django in Ubuntu is quite simple:

sudo apt-get install python-django

Django is installed in the path /var/lib/python-support/python2.5/django

Since I will be using MySQL, I needed to install another package which would let Python connect to it.

sudo apt-get install python-mysqldb

Start New Project

While trying to create a new project, run the following command:

cd /home/me/

django-admin startproject newprojectname

Although the documentation says to use django-admin.py, in Ubuntu Gutsy, you should not use the .py extension. Instead, just use django-admin. The source of this information is a post on Ubuntu Forums: Path to Django Installation.

Start a New Application

Go into the directory of your project. For example, if your project is called newprojectname, then

cd /home/me/newprojectname

Then run the following command

python manage.py startapp newappname

Inspect the Database

If you need to generate a model of your database automatically, you can easily inspect the database by first going into the directory of the project

cd /home/me/newprojectname

and then running this

python manage.py inspectdb

I usually save the output to a file so that I can look at it and make changes to it as required.

python manage.py inspectdb > ~/inspectdb-date.py

In my example, inspectdb-date.py can be used as a models.py file after rearranging the contents (Cleaning Up Generated Models).

Deploy Django with Apache

Although the Django Book has a very good way of explaining this stuff (Using Django with Apache and mod_python), I would like to explain the same thing step-by-step.

Install Apache: sudo apt-get install apache2

Install mod_python: sudo apt-get install libapache2-mod-python

Check if mod_python is enabled: ls /etc/apache2/mods-enabled/mod_python.load and if you see mod_python.load as a result, it is enabled

If mod-python is not enabled: sudo a2enmod mod_python

Restart Apache server: /etc/init.d/apache2 restart

Configure Virtual Host

Your virtual host config file should look something like this

sudo vim /etc/apache2/sites-available/mysite

NameVirtualHost *:80
<VirtualHost *:80>
ServerAdmin admin@mysite.com
ServerName mysite.com
ServerAlias www.mysite.com
DocumentRoot /home/me/mysite/
ErrorLog /home/me/logs/error.log
<Location "/">
SetHandler mod_python
PythonHandler django.core.handlers.modpython
PythonPath "['/home/me/'] + sys.path"
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
PythonDebug On
</Location>
</VirtualHost>

Of course, if it is a production site, PythonDebug On should be omitted.

If you are moving your Django site from one server to another, it might be a good idea to first create a new site on the new server with the same name as the site being transferred. Then just copy all the files and folders into the new site. I don’t know how Django works in this regard but it is possible it keeps a list of projects created.

How Do I do it?

I have created a directory for templates and static (css, images, etc.) files: /home/me/templates/ and /home/me/templates/static/. My Django application resides in /home/me/mysite/. My file looks like

NameVirtualHost 192.168.0.10:80
<VirtualHost 192.168.0.10:80>
ServerAdmin myemail@mydomain.com
ServerName mysite.mydomain.com
DocumentRoot /home/me/templates/
ErrorLog /home/me/logs/error.log
LogFormat "%v %l %u %t \"%r\" %>s %b" comonvhost
CustomLog /home/me/logs/custom.log comonvhost
<Directory /home/me/templates/*>
Options -Indexes
</Directory>
<Location "/">
SetHandler mod_python
PythonHandler django.core.handlers.modpython
PythonPath "['/home/me/'] + sys.path"
SetEnv DJANGO_SETTINGS_MODULE myapp.settings
PythonDebug On
</Location>
<Location "/static">
SetHandler None
</Location>
<Location "/media">
SetHandler None
</Location>
</VirtualHost>

I also created a symlink to the Django admin media files in /home/me/templates/ (my apache root directory) so that http://mydomain.com/admin/ would look the way it’s supposed to with all its GUI intact.

cd /home/me/templates/
ln -s /var/lib/python-support/python2.5/django/contrib/admin/media media

Hat tips to: Django Installation on Apache; Serving the Admin Files;