The Problem
An attempt to use sprunge.us (the only paste-bin worth using) with curl from behind a Squid proxy returns an error.
The Symptoms
Here's the Squid error message in case you forgot:
ERROR
The requested URL could not be retrieved.
While trying to process the request:
POST / HTTP/1.1 User-Agent: curl/7.15.5 (i486-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5 Host: sprunge.us Accept: */* Content-Length: 1117 Expect: 100-continue Content-Type: multipart/form-data; boundary=----------------------------e77c50e200fbThe following error was encountered:
- Invalid Request
Some aspect of the HTTP Request is invalid. Possible problems:
- Missing or unknown request method
- Missing URL
- Missing HTTP Identifier (HTTP/1.0)
- Request is too large
- Content-Length missing for POST or PUT requests
- Illegal character in hostname; underscores are not allowed
Your cache administrator is: abc@123.local
Generated Sun, 25 Oct 2009 14:34:23 GMT by 123.local (squid)
And the entry in the Squid access logs:
1256481202.378 1 10.254.22.109 TCP_MISS/417 1623 POST http://sprunge.us/ - NONE/- text/html
The Fix
Force curl to use HTTP 1.0 instead of the default HTTP 1.1 by adding the "-0" option.
~# iptables -L -n | curl -0 -F 'sprunge=<-' http://sprunge.us
Wait, what?
From the HTTP/1.1 RFC 2616:
Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send "Expect: 100-continue" without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the client SHOULD NOT wait for an indefinite period before sending the request body.
Basically, Squid is HTTP 1.0, and "Expect: 100-continue" in the header is HTTP 1.1, so Squid throws an error. If curl is instructed to use HTTP 1.0, Squid is happy and the request is processed successfully.
Word Count: 356
