Why is curl truncating this query string?

I'm sure the answer to this is going to be some painfully obvious character encoding issue...

I'm using curl on the command line to test some endpoints in a python app. The endpoint takes url params of latitude and longitude. Nothing too special. I put in the command:

curl -v -L http://localhost:5000/pulse/?lat=41.225&lon=-73.1

Server responds, with verbose curl output:

* Connected to localhost (127.0.0.1) port 5000 (#0)
> GET /pulse/?lat=41.225 HTTP/1.1
> User-Agent: curl/7.21.6 (i686-pc-linux-gnu) libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3
> Host: localhost:5000
> Accept: */*
> 
* HTTP 1.0, assume close after body
< HTTP/1.0 500 INTERNAL SERVER ERROR
< Content-Type: application/json
< Content-Length: 444
< Server: Werkzeug/0.8.1 Python/2.7.2+
< Date: Wed, 01 Feb 2012 17:06:29 GMT
< 
{
    "msg": "TypeError: float() argument must be a string or a number", 
    "flag": 0, 
    "stack": [
        "Traceback (most recent call last):", 
        "  File \"engine.py\", line 139, in dispatch_request", 
        "    return getattr(self, 'action_'+endpoint)(request, **values)", 
        "  File \"engine.py\", line 818, in action_getpulse", 
        "    lon = float(request.args.get('lon'))"
    ], 
    "err": 1
* Closing connection #0
}
[1]+  Done

On the second line of that dump, it's obvious that the second param, lon, isn't being sent. What am I doing wrong? Thanks.

The answer to the question, "what am I doing wrong," is that the shell sees the ampersand (&) and thinks that's the end of the command (and puts it into the background). You need to quote it, which is why the answers that quoted the string work. You could just as easily run this:

curl -v -L "http://localhost:5000/pulse?lat=41.225&lon=-73.1"

I think you can try this:

 curl -v -L -d "lat=41.225&lon=-73.1" http://localhost:5000/pulse

by default, this calls POST. If you want to send a GET request

 curl -v -L -G -d "lat=41.225&lon=-73.1" http://localhost:5000/pulse

---

More...
and since you're using localhost, if you were to use https, you'd probably want to include -k as an option to ignore certificate errors

Thanks to Ross for pointing this.