### 3.11 Tuning POST and PUT requests

The main assumption behind the design of the HTTP protocol is that requests are idempotent: since a request can be repeated by a client, a server is allowed to drop a connection at any time. This fact, more than anything else, explains the amazing scalability of the protocol.

This assumption breaks down in the case of POST requests. Indeed, a POST request usually causes some action to be performed (a page to be printed, a significant amount of money to be transferred from your bank account, or, in Florida, a vote to be registered), and such a request should not be repeated.

The only solution to this problem is to reserve HTTP to idempotent activities, and use reliable protocols for action-effecting ones. Notwithstanding that, HTTP/1.1 makes a weak attempt at making POST requests slightly more reliable and efficient than they are in HTTP/1.0.

When speaking to an HTTP/1.1 server, an HTTP client is allowed to request that the server check a priori whether it intends to honour a POST request. This is done by sending an expectation, a specific header with the request, ‘`Expect: 100-continue`’, and waiting for either an error message or a ‘`100 Continue`’ reply from the server. If the latter arrives, the client is welcome to send the rest of the POST request1.

Polipo's behaviour w.r.t. client expectations is controlled by the variable `expectContinue`. If this variable is false, Polipo will never send an expectation to the server; if a client sends an expectation, Polipo will fail the expectation straight away, causing the client (if correctly implemented) to retry with no expectation. If `expectContinue` is `maybe` (the default), Polipo will behave in a standards-compliant manner: it will forward expectations to the server when allowed to do so, and fail client expectations otherwise. Finally, if `expectContinue` is `true`, Polipo will always send expectations when it is reasonable to do so; this violates the relevant standards and will break some websites, but might decrease network traffic under some circumstances.

#### Footnotes

[1] This, of course, is only part of the story. Additionally, the server is not required to reply with ‘`100 Continue`’, hence the client must implement a timeout. Furthermore, according to the obsolete RFC2068, the server is allowed to spontaneously send ‘`100 Continue`’, so the client must be prepared to ignore such a reply at any time.