Bug: *PRINT-BASE* affects radix of Content-Length header in reply

[Chaitanya Gupta]

The radix used to print the value of the Content-Length header in
reply is affected by the value set for *PRINT-BASE* in my SLIME REPL.
This should not happen; Content-Length should always be in base 10 I
believe.

Here's a minimal test case:

(hunchentoot:define-easy-handler (content-length-test :uri
"/content-length-test")
    ()
  "Foo Bar Baz")

When *PRINT-BASE* is 10,

$ curl -v http://localhost:4242/content-length-test
* About to connect() to localhost port 4242 (#0)
...snipped...
< HTTP/1.1 200 OK
< Content-Length: 11
...snipped...
* Connection #0 to host localhost left intact
Foo Bar Baz

When *PRINT-BASE* is 16,

$ curl -v http://localhost:4242/content-length-test
* About to connect() to localhost port 4242 (#0)
...snipped...
< HTTP/1.1 200 OK
< Content-Length: B
...snipped...
* Excess found in a non pipelined read: excess = 11 url =
/content-length-test (zero-length body)
* Connection #0 to host localhost left intact

I am running Hunchentoot 1.2.19 on SBCL 1.1.4 on OS X Mountain Lion.

Chaitanya